WebSocket vs REST APIs on Crypto Exchanges: What's the Difference
If you are wiring a strategy up to an exchange, one of the first technical forks you hit is WebSocket vs REST APIs on a crypto exchange. Both let your code talk...
Iceberg orders let large traders hide most of their size in the order book, showing only a small tip at a time. Here is how they work and what they mean for your automated fills.
Watch a crypto order book long enough and you will see something odd. A price level shows only a modest amount of size, you send orders into it, and yet the level keeps refilling as if it never runs out. You are almost certainly looking at an iceberg order. Iceberg orders are one of the most common ways large traders hide their true size, and if you automate execution, they quietly shape the fills you get. This guide explains what iceberg orders are, how they work, and what they mean for anyone running orders through a signal-driven system.
The short version: an iceberg order is a large order that reveals only a small slice of itself at any moment. You see the tip; the bulk stays below the surface, which is exactly where the name comes from.
An iceberg order is a large limit order that is split, by the exchange or by the trader, into a visible portion and a hidden reserve. Only the visible portion, called the display quantity or peak, appears in the public order book. When that visible slice is filled, the exchange automatically posts the next slice from the hidden reserve at the same price, and it keeps doing this until the whole order is done or cancelled.
So a trader who wants to buy 500 BTC might show only 5 BTC at a time. The market sees a 5 BTC bid; as soon as it fills, another 5 BTC appears. To an observer the level looks small but stubborn, masking a much larger buyer behind it.
The purpose is concealment. A resting 500 BTC bid is a signal to everyone else, and that signal moves the market before the order is even filled. By showing only a fraction, the trader shrinks their footprint and avoids tipping off faster participants.
Mechanically, an iceberg is a sequence of small limit orders released one after another. Some exchanges support them natively as a built-in order type; others do not, so traders or execution tools recreate the behavior by repeatedly posting small slices themselves.
When an exchange handles the iceberg natively, three things matter. The peak size is what the book displays. The total size is the full amount you are trying to fill. And each refill usually goes to the back of the queue at that price, so the hidden portion does not keep front-of-line priority. That last detail matters: an iceberg is not a way to jump the queue. Each new slice waits its turn behind orders already resting at that level.
If you want a refresher on how price levels, queue priority, and depth actually behave, our guide on how crypto exchange order books work covers the fundamentals iceberg orders build on.
The main reason is market impact. Large orders that sit fully visible tend to push price against the trader. Other participants see the size, trade ahead of it, or pull their own liquidity, and the trader ends up filling at worse and worse prices. Hiding size reduces that impact.
A second reason is information leakage. In markets where many bots read the order book in real time, a large visible order is a data point competitors can trade around. Concealing it keeps intentions private. A third reason is discipline: committing size to a hidden order at a chosen price executes a plan mechanically instead of reacting to every tick.
Here is where it gets practical. Iceberg orders change what the visible order book is telling you, and automated systems that trust the book at face value can be misled.
Send a market order into what looks like thin liquidity and you might expect the price to move several levels. If a hidden iceberg is sitting there, your order fills against slice after slice at nearly the same price, and you get a better result than the visible depth suggested. That is the friendly case.
The unfriendly case is the reverse. You place a limit order at a level, expecting to be near the front of the queue, but a hidden iceberg keeps feeding new size around you, and your fill takes far longer than the displayed depth implied. Your automation waits, the market moves, and the edge in your original signal decays.
Either way the lesson is the same: displayed depth is an estimate, not a promise. This is one more reason slippage in automated trading is hard to eliminate, and why your order-type choice matters. If you are weighing aggressive against passive execution, our breakdown of market versus limit orders pairs well with this topic.
Not reliably, and it is honest to say so. You cannot see a hidden reserve directly, because concealment is the entire point. What you can observe are footprints: a level that refills repeatedly after being hit, trades printing far larger than the displayed size, or a price that stalls at a round number despite steady selling.
These are clues, not certainties. Plenty of ordinary refilling happens because many independent traders post at popular levels. Automation that assumes every stubborn level is an iceberg will misfire as often as it helps. Treat hidden liquidity as uncertainty to manage, not a pattern to predict.
It helps to place iceberg orders next to types you may already automate. A post-only order is about fee treatment and never crossing the spread; our post on post-only orders explains that mechanic. An iceberg is about hiding size, and solves a different problem. A plain limit order shows its full size; an iceberg is essentially a limit order wearing a smaller mask. A market order ignores concealment entirely, taking whatever liquidity exists, hidden reserves included.
Most retail-facing exchanges do not expose native iceberg orders through their public trading APIs, so as an automated trader you will more often be trading around other people's icebergs than placing your own.
A few habits keep hidden liquidity from surprising your system:
The theme across all of these is humility about the order book. Automation removes emotion, but it does not grant you a clear view of hidden size.
Yes. Iceberg orders are a standard, widely supported execution feature on many venues, including traditional and crypto markets. They hide displayed size, which is different from illegal practices like spoofing, where orders are placed with no intent to fill. An iceberg fully intends to execute; it just does so a slice at a time.
No. They reduce market impact and information leakage, but each hidden slice still waits its turn in the queue and fills at the resting price. Concealment helps large orders avoid moving the market against themselves; it does not promise any particular outcome.
Usually not directly, because most retail exchange APIs do not expose a native iceberg type. Traders who want iceberg-like behavior typically slice a large order into smaller timed orders themselves. For most automated setups, standard market and limit orders are what you will actually send.
A fully hidden order shows nothing in the book at all, while an iceberg shows a small visible tip and hides the rest. Support varies by exchange, and hidden orders often pay taker-style fees because they provide no visible liquidity.
Hidden liquidity is one of many reasons execution is harder than it looks: the order book you see is only part of the story. SignalToExchange is a non-custodial webhook relay that takes one variable off your plate. It receives your signal from TradingView or an automation platform and submits the order to your exchange using trade-only API keys, so your funds never leave the exchange and no one, including us, can withdraw them. We focus on reliable, low-latency submission of standard order types; you control the logic, and the relay handles execution. If that is what you need, request access or start your free trial with SignalToExchange.
Automated trading involves risk. SignalToExchange is execution infrastructure and does not provide financial advice, trading signals, or guarantees of any kind.
Non-custodial execution. Trade-only API keys. Independent infrastructure built for reliability.
Request Early AccessTrade-only API key enforcement. No withdrawal permissions. No custody.