# Iceberg order: display size, refills and API fields

URL: https://fincodelabs.com/en/blog/iceberg-order · Publisher: Fincode (Fincode Yazılım ve Teknoloji A.Ş.), Istanbul, Turkey · Category: Exchange APIs · Published: 2026-11-06 · Updated: 2026-11-06

Iceberg order explained: display size, why a refill loses queue priority on CME, hidden vs iceberg, and crypto API fields by venue, read 6 November 2026.

**Short answer:** An **iceberg order** is a limit order that shows only part of its size, the display quantity, in the order book and keeps the rest hidden, showing a new slice each time the visible one fills. CME Globex documents that each refreshed slice joins the back of the queue at its price; the crypto API documents read on 6 November 2026 do not say how a refill is ranked. Binance Spot, Deribit, Gate and Kraken document native iceberg fields and OKX an algo order that splits into limit orders; KuCoin withdrew its iceberg fields on 3 August 2026.

Iceberg orders matter to anyone placing them through an API and to anyone reading order book data, whose depth figures undercount what can trade. Venue facts below come from official documentation or live public endpoints read on 6 November 2026.

This describes mechanics only, not a venue recommendation or a claim that hiding size gets a better price; automated trading can lose money. Availability depends on your jurisdiction and each platform's terms. Article 99/A of Capital Markets Law No. 6362 treats activity by foreign crypto-asset platforms directed at Turkish residents as unauthorized.

## What is an iceberg order?

An iceberg order is a resting limit order that the venue splits into a visible part and a hidden remainder, so the book never shows more than the size you chose to display.

- **Total quantity** is what the order may trade in all.
- **Display quantity** is the slice the book shows: `icebergQty` at Binance, `display_amount` at Deribit, `displayvol` or `display_qty` at Kraken, `iceberg` at Gate, display quantity on CME Globex.
- **Hidden remainder** is held by the matching engine; CME's order qualifier page calls it "booked but not displayed".

> **Hypothetical example.** A buy limit order for 0.5 BTC on Binance Spot with `icebergQty` 0.01 shows 0.01 at its price. Binance counts parts as CEIL(quantity / icebergQty), here 50, and BTCUSDT allowed up to 100 parts on 6 November 2026. With `icebergQty` 0.004 the order would need 125 parts and would fail with "Filter failure: ICEBERG_PARTS".

## How does an iceberg order refill?

When the displayed slice is filled, the venue shows a new slice from the hidden remainder, and on CME Globex that new slice goes to the back of the queue at its price.

CME's matching algorithm page, read 6 November 2026, has the most complete rules found:

- A display quantity order is filled on its working displayed quantity at its current timestamp.
- After the match event it is refreshed with the lesser of its display quantity and its remainder, or with what is left of the slice after a partial fill.
- Its priority then becomes the lowest at that price: the end of the queue.
- Under pro rata allocation it takes part only with its displayed quantity.
- Exception: an incoming order at least as large as the displayed quantity at a price is matched FIFO in place of the product's algorithm, hidden quantity included.

CME's order qualifiers page adds that SOFR futures allow a display ratio of at most 1:60 and that some FX and interest rate contracts do not accept display quantity.

Crypto documents say less. Deribit's API specification says the display amount is refreshed to its initial value after a match consumes it, without saying where the slice queues. Binance's amend FAQ says an iceberg's visible quantity changes only if the new quantity is below it. No Binance, Deribit, Gate, Kraken or OKX page read on 6 November 2026 states whether a refill keeps time priority, so a fill model should not assume it does.

> **Hypothetical example, CME-style refresh.** Three buy orders rest at one price: an iceberg (ICE) showing 1 of 5, then B for 2, then C for 1. Four sell orders arrive.
>
> **One price level under CME's documented refresh rule (hypothetical sizes)**
>
> | Event | Trades | Level shows | Queue after (shown / left) | Traded so far |
> | --- | --- | ---: | --- | ---: |
> | Start | None | 4 | ICE 1/5, B 2, C 1 | 0 |
> | Sell 1 | ICE 1 | 4 | B 2, C 1, ICE 1/4 | 1 |
> | Sell 3 | B 2, C 1 | 1 | ICE 1/4 | 4 |
> | Sell 1 | ICE 1 | 1 | ICE 1/3 | 5 |
> | Sell 1 | ICE 1 | 1 | ICE 1/2 | 6 |
>
> After the first trade the level still shows 4; by the end 6 have traded at a price that never showed more than 4.

## Hidden order vs iceberg order

A hidden order shows nothing in the book, an iceberg order shows a slice, and an algorithmic iceberg is a series of limit orders placed by a venue's algo service.

**What the book shows, by order kind, from documents read 6 November 2026**

| Kind | Shown in the book | Documented at |
| --- | --- | --- |
| Plain limit order | Full remaining size | Every venue here |
| Native iceberg | Display quantity only | Binance Spot, CME Globex, Deribit, Gate, Kraken |
| Hidden order | Nothing | None here: KuCoin dropped its `hidden` flag on 3 August 2026; Gate's spot iceberg cannot hide the whole amount |
| Algorithmic iceberg | Child limit orders; no hidden part described | OKX `smart_iceberg` |

Fees can differ from a plain resting order. Gate's futures order model says hidden portions are charged taker fees, and Deribit's specification says the `fee_role` in its transaction log can differ from the user's trade role when an iceberg was involved in matching. Read the fee fields on each fill rather than assuming the maker rate; see [transaction cost analysis](https://fincodelabs.com/en/blog/transaction-cost-analysis).

An iceberg hides size that can trade. Entering orders with no intention of executing them, of any type, can amount to market abuse, by hand or by software.

## Iceberg order API fields by venue

Five of the crypto venues checked document an iceberg route in their API material as of 6 November 2026, four as an order field and OKX as an algo order type; KuCoin withdrew its fields on 3 August 2026.

**Iceberg fields in official API documentation, read 6 November 2026 (alphabetical)**

| Venue | Field | Documented rules |
| --- | --- | --- |
| Binance Spot | `icebergQty` (REST, WebSocket API); `MaxFloor (111)` on FIX; leg fields such as `aboveIcebergQty` | `timeInForce` GTC; below the quantity; LOT_SIZE applies; CEIL(quantity / icebergQty) within ICEBERG_PARTS; symbol must allow icebergs |
| Deribit | `display_amount` on `private/buy`, `private/sell`, `private/edit` | Instrument's minimum iceberg amount, amount step and maximum total-to-display ratio; not above the total; not for options or combos |
| Gate | `iceberg` on spot and futures orders | Spot: amount to display, 0 or null for a normal order. Futures: display size; hidden portions charged taker fees |
| Kraken | `ordertype=iceberg` with `displayvol` (REST); `display_qty` ([WebSocket v2](https://docs.kraken.com/api/docs/websocket-v2/add_order)) | Display at least 1/15 of the order quantity |
| KuCoin | `hidden`, `iceberg`, `visibleSize`: withdrawn | Changelog, 3 August 2026: Classic REST order endpoints reject them with error 400413; current order pages omit them |
| OKX | `ordType` `smart_iceberg` on `POST /api/v5/trade/order-algo` | `szLimit`, `lmtOrderNumber`, `aggressiveness`, optional `pxLimit`; up to 100 pending; no amending |

- **Binance's limit moved.** Its changelog scheduled ICEBERG_PARTS for all symbols at 25 around 18 December 2025, 50 on 11 February 2026 and 100 on 12 March 2026. On 6 November 2026 `exchangeInfo` returned 100 for BTCUSDT, with no MAX_NUM_ICEBERG_ORDERS or exchange-level filter, so read the values at run time.
- **Binance's two lists differ.** The parameter table lists `icebergQty` for LIMIT, STOP_LOSS_LIMIT and TAKE_PROFIT_LIMIT; the notes say any LIMIT or LIMIT_MAKER order can be an iceberg, and order-list fields such as `workingIcebergQty` accept LIMIT_MAKER legs. Test your combination on the Spot Testnet.
- **OKX.** Query endpoints accept both `iceberg` and `smart_iceberg`, and instruments carry `maxIcebergSz`. OKX describes splits into limit orders, not a hidden reserve; slicing on a clock is covered in [TWAP order](https://fincodelabs.com/en/blog/twap-order).
- **Sources.** [Gate's API page](https://www.gate.com/docs/developers/apiv4/en/) loaded only in part on 6 November 2026; its changelog records spot and futures icebergs, and the field rules come from Gate's official SDK documentation. KuCoin's official [Python SDK model](https://github.com/Kucoin/kucoin-universal-sdk/blob/main/sdk/python/kucoin_universal_sdk/generate/spot/order/model_add_order_req.py) still lists the withdrawn fields: an SDK does not prove a venue accepts a field. Bybit's [V5 place order page](https://bybit-exchange.github.io/docs/v5/order/create-order) listed no iceberg or display-size parameter that day.

## How iceberg orders show in order book data

Depth feeds show only the displayed slice, so more can trade at a price than the book ever showed there, and public data does not say whether an iceberg caused it.

- **Level 2.** Aggregated depth adds up displayed quantities only; see [Level 2 order book data](https://fincodelabs.com/en/blog/level-2-order-book).
- **Level 3.** Kraken's authenticated WebSocket v2 `level3` channel lists hidden quantity of iceberg orders among what it excludes.
- **Trades.** Each fill prints as a trade, and the level can return to its old size, as in the table above. A new order or a re-quote looks the same, and public data cannot tell them apart; this guide does not treat it as a trading signal.

For software this means:

- A fill simulator capped at displayed size understates what can trade, and queue estimates from visible size alone can be wrong either way.
- A level that does not shrink after a trade is not proof of a missed update; check update IDs as in [maintaining a local order book](https://fincodelabs.com/en/blog/websocket-order-book) before resynchronizing.
- Depth-based measures use displayed quantity only, as the [order book imbalance formula](https://fincodelabs.com/en/blog/order-book-imbalance-formula) guide notes.
- Your own iceberg fills arrive as partial fills of one order; see [partial fill handling](https://fincodelabs.com/en/blog/partial-fill-handling).

Historical data carries its own terms: Binance's dataset at data.binance.vision is licensed for non-commercial use only (CC BY-NC-SA 4.0) under [terms updated 26 August 2026](https://github.com/binance/binance-public-data/blob/master/TERMS_AND_CONDITIONS.md).

## Checking an iceberg order against Binance's live filters

Read the symbol's rules from `exchangeInfo` at startup and test each documented condition before sending, using `Decimal` rather than float.

The script (Python 3.11, `requests`) calls only Binance's public market data host, with no key, and was run on 6 November 2026. It places no order, which needs a real key; the exchange's checks remain final, and filters such as NOTIONAL also apply.

```python
import math
from decimal import Decimal, InvalidOperation
import requests

URL = "https://data-api.binance.vision/api/v3/exchangeInfo"   # public, no key

def rules(symbol):
    r = requests.get(URL, params={"symbol": symbol}, timeout=10)
    try:
        body = r.json()
    except ValueError:
        body = None
    body = body if isinstance(body, dict) else {}
    if not 200 <= r.status_code < 300:           # status first, then .get
        raise RuntimeError(f"HTTP {r.status_code}: {body.get('msg', 'no message')}")
    (sym,) = body.get("symbols", [])             # exactly one symbol, or fail
    filters = {}
    for f in sym.get("filters", []):
        if f["filterType"] in filters:           # a duplicate must not win silently
            raise RuntimeError(f"duplicate filter {f['filterType']}")
        filters[f["filterType"]] = f
    return sym.get("icebergAllowed", False), filters

def dec(text):
    try:
        d = Decimal(text)                        # float("1e400") would be inf
    except InvalidOperation:
        raise ValueError(f"not a number: '{text}'") from None
    if not d.is_finite() or d <= 0:
        raise ValueError(f"not finite and positive: '{text}'")
    return d

def check(qty, iceberg_qty, allowed, filters, tif="GTC"):
    q, iq = dec(qty), dec(iceberg_qty)
    lot, parts = filters.get("LOT_SIZE"), filters.get("ICEBERG_PARTS")
    if not (allowed and lot and parts):
        return ["iceberg not allowed or filters missing: do not guess"]
    errors = [] if tif == "GTC" else ["timeInForce must be GTC"]
    if iq >= q:
        errors.append("icebergQty must be less than quantity")
    for name, v in (("quantity", q), ("icebergQty", iq)):
        if not Decimal(lot["minQty"]) <= v <= Decimal(lot["maxQty"]) \
                or v % Decimal(lot["stepSize"]):
            errors.append(f"{name} fails LOT_SIZE")
    n = None if errors else math.ceil(q / iq)
    if n and n > parts["limit"]:
        errors.append(f"{n} parts > ICEBERG_PARTS {parts['limit']}")
    return errors or [f"{n} parts, passes these checks"]

allowed, filters = rules("BTCUSDT")
print("icebergAllowed", allowed, "ICEBERG_PARTS", filters.get("ICEBERG_PARTS", {}).get("limit"))
for qty, iq in [("0.5", "0.01"), ("0.5", "0.004"), ("0.5", "0.5"),
                ("0.5", "1e-400"), ("1e400", "0.01"), ("0.5", "nan")]:
    try:
        print(qty, iq, "->", "; ".join(check(qty, iq, allowed, filters)))
    except ValueError as err:
        print(qty, iq, "-> rejected:", err)
try:
    rules("NOTASYMBOL")
except RuntimeError as err:
    print("bad symbol ->", err)
```

Output on 6 November 2026:

```
icebergAllowed True ICEBERG_PARTS 100
0.5 0.01 -> 50 parts, passes these checks
0.5 0.004 -> 125 parts > ICEBERG_PARTS 100
0.5 0.5 -> icebergQty must be less than quantity
0.5 1e-400 -> icebergQty fails LOT_SIZE
1e400 0.01 -> quantity fails LOT_SIZE
0.5 nan -> rejected: not finite and positive: 'nan'
bad symbol -> HTTP 400: Invalid symbol.
```

A float would turn "1e400" into infinity and "1e-400" into 0.0; `Decimal` keeps both as numbers that fail LOT_SIZE.

For integration work in general, see Fincode's [exchange API integration](https://fincodelabs.com/en/services/exchange-api-integration) page; naming Binance, Deribit, Gate, Kraken, KuCoin or OKX here does not mean Fincode integrates them or has built on them. More guides: [crypto exchange API guides](https://fincodelabs.com/en/blog/crypto-exchange-apis).

## Frequently asked questions

### Can an iceberg order be fully hidden?

Not on the venues checked here. Gate's spot documentation does not support hiding the whole amount, and an order that shows nothing is a hidden order, which KuCoin offered as a separate flag until 3 August 2026.

### Do iceberg orders pay maker fees?

Not necessarily. Gate's futures documentation charges taker fees on hidden portions, and Deribit says the fee role can differ from the trade role when an iceberg was involved.

### Does an iceberg refill keep its place in the queue?

On CME Globex it does not: the refreshed slice goes to the end of the queue. The crypto API documents read on 6 November 2026 do not say.

### How many parts can a Binance iceberg order have?

CEIL(quantity / icebergQty) must not exceed the symbol's ICEBERG_PARTS filter, which was 100 for BTCUSDT on 6 November 2026.

### Is an iceberg order the same as a TWAP order?

No. An iceberg hides part of one resting order at a price; a TWAP order sends slices on a time schedule.

## Sources

- [Binance Spot API documentation: REST API (icebergQty, order rules, order lists)](https://github.com/binance/binance-spot-api-docs/blob/master/rest-api.md)
- [Binance Spot API documentation: Filters (ICEBERG_PARTS, LOT_SIZE, MAX_NUM_ICEBERG_ORDERS)](https://github.com/binance/binance-spot-api-docs/blob/master/filters.md)
- [Binance Spot API changelog (ICEBERG_PARTS raised to 25, 50 and 100)](https://github.com/binance/binance-spot-api-docs/blob/master/CHANGELOG.md)
- [Binance Spot API documentation: Error codes and messages (IcebergQty exceeds QTY, MaxFloor)](https://github.com/binance/binance-spot-api-docs/blob/master/errors.md)
- [Binance Spot API documentation: Order Amend Keep Priority FAQ](https://github.com/binance/binance-spot-api-docs/blob/master/faqs/order_amend_keep_priority.md)
- [CME Group Client Systems Wiki: CME Globex Matching Algorithm Steps (display quantity with FIFO and pro rata)](https://cmegroupclientsite.atlassian.net/wiki/spaces/EPICSANDBOX/pages/457218521/CME+Globex+Matching+Algorithm+Steps)
- [CME Group Client Systems Wiki: Order Qualifiers (display quantity)](https://cmegroupclientsite.atlassian.net/wiki/spaces/EPICSANDBOX/pages/457218264/Order+Qualifiers)
- [Deribit API OpenAPI specification, version 2.1.1 (display_amount, refresh_amount, fee_role)](https://docs.deribit.com/specifications/deribit_openapi.json)
- [Gate API v4 official Python SDK documentation: spot Order model (iceberg)](https://github.com/gateio/gateapi-python/blob/master/docs/Order.md)
- [Gate API v4 official Python SDK documentation: FuturesOrder model (iceberg, taker fees on hidden portions)](https://github.com/gateio/gateapi-python/blob/master/docs/FuturesOrder.md)
- [Kraken API documentation: Add Order, REST (ordertype iceberg, displayvol)](https://docs.kraken.com/api/docs/rest-api/add-order)
- [Kraken API documentation: WebSocket v2 level3 channel (excludes hidden iceberg quantity)](https://docs.kraken.com/api/docs/websocket-v2/level3)
- [KuCoin API documentation: Changelog, 3 August 2026 entry (hidden and iceberg orders discontinued, error 400413)](https://www.kucoin.com/docs-new/change-log)
- [OKX API v5 documentation: Place algo order (smart_iceberg), algo order limits, maxIcebergSz](https://www.okx.com/docs-v5/en/)
- [Capital Markets Law No. 6362, Article 99/A (Turkish, consolidated text)](https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6362.pdf)

> This guide is general information about software and markets, not investment, legal or tax advice. Automated trading can lose money, past or backtested performance does not guarantee future results, and the rules that apply depend on your jurisdiction and your exchange's terms. Sources, checks and corrections: see the [editorial policy](https://fincodelabs.com/en/editorial-policy).

---

Published by Fincode (Fincode Yazılım ve Teknoloji A.Ş.), a software company in Istanbul, Turkey: https://fincodelabs.com/en/blog/iceberg-order

Cite as: Fincode, "Iceberg order: display size, refills and API fields", updated November 6, 2026, https://fincodelabs.com/en/blog/iceberg-order