A crypto iceberg order displays only a chosen slice of a larger limit order while keeping the remaining quantity hidden from the public order book. The visible size controls disclosure, not the total amount authorized to trade. As slices fill, the venue replenishes them under its own rules, so check the full quantity, available funds, replenishment priority and minimum display constraints before submission.
A book showing 12 units can represent an instruction to buy 100. That distinction matters twice: when deciding how much capital the order can commit, and when interpreting the liquidity other traders can see. An iceberg changes how an order appears; it does not make the undisplayed remainder disappear.
Keep four quantities in the same record
The original total is the amount the trader authorizes. Cumulative fills are the amount already executed. The current displayed remainder is the slice presently visible. The hidden reserve is the working quantity waiting behind that slice.
For an active order with no canceled quantity or amendments, the useful identity is:
original total = cumulative fills + displayed remainder + hidden reserve
This identity describes a particular observation after any replenishment has settled. It does not mean a public order-book feed reveals all four fields. A price level can aggregate many participants' orders, and public displayed depth cannot identify a particular trader's hidden reserve.
Kraken's iceberg order explanation distinguishes display quantity from total order quantity and describes replenishment as the displayed portion fills. Treat that as venue documentation, not a promise that another exchange or trading application implements the same mechanism.
For a buy, the full unfilled quantity remains a potential future acquisition. For a sell, it remains an instruction that can dispose of inventory. The partial-fill management guide covers how to reconcile executions and actual holdings; the extra task here is retaining the hidden working remainder alongside them.
A visible-size ledger for one hypothetical buy
Assume an invented spot buy for 100 ABC at a limit of 50 USDT per ABC, with a displayed slice of 12 ABC. The order rests without immediately crossing the spread. Assume each exhausted slice replenishes to 12 while sufficient reserve remains, no amendments occur, and all fills below execute at exactly 50. Ignore fees solely to keep the quantity ledger readable.
| Checkpoint | Cumulative bought, ABC | Visible remainder, ABC | Hidden reserve, ABC | Total still working, ABC |
|---|---|---|---|---|
| Accepted and resting | 0 | 12 | 88 | 100 |
| First slice receives a 5-unit fill | 5 | 7 | 88 | 95 |
| Remaining 7 fills; next slice replenishes | 12 | 12 | 76 | 88 |
| Second slice fills; third replenishes | 24 | 12 | 64 | 76 |
| Third slice receives a 3-unit fill | 27 | 9 | 64 | 73 |
At the final checkpoint, 27 ABC have traded for 1,350 USDT. Another 73 ABC can still trade under the instruction, representing up to 3,650 USDT of additional gross purchases at the limit. The visible nine ABC represent only 450 USDT. Using that displayed amount as the remaining capital commitment would omit 3,200 USDT of hidden purchases.
Before any fills, the complete order can purchase up to 5,000 USDT of ABC before fees. A limit buy can execute at a better price, but budgeting only the initial displayed 600 USDT would not fund this plan. Actual available-funds and fee requirements depend on the venue and account.
If the remaining 73 ABC are subsequently confirmed canceled, the result is 27 bought and 73 canceled. Cancellation does not reverse the acquired ABC. Until the terminal state is known, a cancellation request alone should not turn the working remainder into zero.
A smaller display can fail validation
Visible size is constrained by the exact product and interface. Binance's Spot new-order documentation allows icebergQty for LIMIT and LIMIT_MAKER orders and requires GTC when icebergQty is supplied. Do not carry those parameter rules into a futures API merely because it shares the venue's name.
Binance's Spot filters define the iceberg part count as CEIL(quantity / icebergQty) and apply a symbol's ICEBERG_PARTS limit. Quantity and display quantity also face lot-size rules. Obtain the current symbol filters rather than copying an example limit from documentation.
Using a hypothetical maximum of ten parts, the 100-unit example with a 12-unit display needs CEIL(100 / 12) = 9 parts. A six-unit display needs 17 parts and fails that assumed constraint. Ten units is the smallest display compatible with this part-count rule alone; other filters may still reject it.
Kraken's Add Order API reference instead specifies a minimum displayvol of one fifteenth of total volume. For a hypothetical 100-unit order on a whole-unit grid, that fraction requires rounding up from 6.666… to seven displayed units, before checking other requirements. Neither example establishes a live trading minimum.
These are different constraints. A quantity that satisfies one does not establish validity on the other. The exchange order minimums worksheet explains how quantity increments, price ticks, notional and available funds interact; an iceberg adds display-specific validation to that work.
Replenishment has a queue consequence
An order that repeatedly reveals the same size does not necessarily preserve the original slice's waiting time. Kraken's exchange trading rules state that after displayed quantity fills, the next display quantity joins the back of that price queue.
Suppose the first slice fills while other traders have queued at the same price. Under that documented rule, replenishment does not jump ahead of those orders. A smaller display can therefore mean more replenishment events and more occasions to wait behind other liquidity. It does not follow that a smaller display always improves execution or that a larger one guarantees faster completion.
The limit still matters. If sellers stop reaching the hypothetical buy limit, the remaining instruction can wait despite its replenishment capability. Our market versus limit order comparison explains that price protection and completion certainty are separate choices.
Concealment is limited, and fills can still be unfavorable
An iceberg reduces direct disclosure of total size. It does not guarantee anonymity or prevent other participants from suspecting reserve liquidity after repeated executions and replenishments. A public observer also cannot prove a specific hidden total merely because displayed size repeatedly returns: other orders can arrive at the same level.
Execution quality remains a separate question. A resting buy can fill shortly before prices fall, leaving acquired inventory worth less. The maker adverse-selection guide examines those fill-conditioned price moves; hiding more quantity does not remove that risk. Displayed depth also understates undisplayed interest, while cancellations can remove displayed interest, as the order-book depth guide explains.
Choose the tool according to the execution problem. An iceberg governs displayed quantity and replenishment. A schedule that targets time intervals or expected market volume makes a different decision. The TWAP versus VWAP execution comparison covers those scheduling choices. A venue may combine mechanisms, but the labels alone do not establish how the combined order behaves.
Write the full obligation before choosing the slice
Record total quantity, limit, display quantity, maximum gross commitment, fee allowance, exact venue product, valid time in force and a review deadline. Add the current instrument rules, expected replenishment priority and the method used to reconcile fills and cancellation.
Then test two failures: the market stops reaching the limit after a partial fill, and the smallest intended display fails venue validation. In the first case, specify who decides the remainder's fate. In the second, do not silently enlarge total quantity or displayed size to obtain acceptance; revisit the authorized configuration.
This article explains exchange order mechanics, without asserting an iceberg control exists in KLINEO. The operational record should always answer two different questions: how much has traded, and how much more remains authorized to trade.
Editorial method: Prepared with AI assistance from official exchange documentation reviewed on 23 October 2026. The quantity ledger, prices and example filter limit are hypothetical; arithmetic was checked. No live order or execution outcome is represented.