Iceberg order: display size, refills and API fields

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".

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.

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.

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.

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.

• 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.
• Sources. Gate's API page (opens in a new tab) 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 (opens in a new tab) still lists the withdrawn fields: an SDK does not prove a venue accepts a field. Bybit's V5 place order page (opens in a new tab) 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.
• 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 before resynchronizing.
• Depth-based measures use displayed quantity only, as the order book imbalance formula guide notes.
• Your own iceberg fills arrive as partial fills of one order; see 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 (opens in a new tab).

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.

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 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.

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) (opens in a new tab)
• Binance Spot API documentation: Filters (ICEBERG_PARTS, LOT_SIZE, MAX_NUM_ICEBERG_ORDERS) (opens in a new tab)
• Binance Spot API changelog (ICEBERG_PARTS raised to 25, 50 and 100) (opens in a new tab)
• Binance Spot API documentation: Error codes and messages (IcebergQty exceeds QTY, MaxFloor) (opens in a new tab)
• Binance Spot API documentation: Order Amend Keep Priority FAQ (opens in a new tab)
• CME Group Client Systems Wiki: CME Globex Matching Algorithm Steps (display quantity with FIFO and pro rata) (opens in a new tab)
• CME Group Client Systems Wiki: Order Qualifiers (display quantity) (opens in a new tab)
• Deribit API OpenAPI specification, version 2.1.1 (display_amount, refresh_amount, fee_role) (opens in a new tab)
• Gate API v4 official Python SDK documentation: spot Order model (iceberg) (opens in a new tab)
• Gate API v4 official Python SDK documentation: FuturesOrder model (iceberg, taker fees on hidden portions) (opens in a new tab)
• Kraken API documentation: Add Order, REST (ordertype iceberg, displayvol) (opens in a new tab)
• Kraken API documentation: WebSocket v2 level3 channel (excludes hidden iceberg quantity) (opens in a new tab)
• KuCoin API documentation: Changelog, 3 August 2026 entry (hidden and iceberg orders discontinued, error 400413) (opens in a new tab)
• OKX API v5 documentation: Place algo order (smart_iceberg), algo order limits, maxIcebergSz (opens in a new tab)
• Capital Markets Law No. 6362, Article 99/A (Turkish, consolidated text) (opens in a new tab)

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.