Every exchange that offers derivatives receives the same ticket. A user gets liquidated, looks at the chart, sees that price never touched their liquidation level, and writes: "There is no such wick on my chart."
Most operations teams treat this as user error. Usually it is not. The user genuinely is not seeing that wick — because on the timeframe they are looking at, it genuinely is not there. And the reason is an architectural decision.
Where the problem comes from
An exchange chart offers timeframes: 1 minute, 5 minutes, 15 minutes, 1 hour, 4 hours, daily. The deceptively simple question is: where do those candles come from?
There are two answers, and they produce entirely different systems.
Approach A: each timeframe is sourced separately
The system aggregates each timeframe independently, or pulls each one separately from a data provider. Five-minute candles come from one stream, hourly candles from another. It is easy to build, and each timeframe looks correct on its own.
The problem: they are under no obligation to agree with one another. Network latency, a tick dropped on one stream, differing aggregation windows — any one of these is enough for a spike visible on the 1-minute chart to disappear on the 15-minute. Both are "correct". They simply do not describe the same thing.
Approach B: one base candle, everything else derived
Only the 1-minute candle is independently sourced and stored. Every timeframe above it is computed mathematically from that: a 5-minute candle is the open, high, low and close of five 1-minute candles. No other source is consulted.
The result: timeframes cannot contradict each other. If a wick exists on the 1-minute chart, it exists on the 15-minute too — because the second is produced from the first. Otherwise it exists on neither.
The difference is operational, not philosophical. Under approach A, "which chart is right?" has no answer. Under approach B the answer is always the same: the 1-minute candle is authoritative and everything else follows from it. That turns an argument into a calculation.
Why it detonates specifically at liquidation
In ordinary trading this inconsistency is invisible. A user looks at the 15-minute chart, opens a position, closes it; two timeframes diverging by a few ticks changes nothing.
Liquidation is different, because liquidation hangs on a single instant — the second price touched the liquidation level. And that instant is very often a wick: a move where the market spikes and retraces within seconds. Precisely the kind of event that can appear on one timeframe and vanish on another.
So the system confronts the user at the one event type where the inconsistency is most visible, at the moment when the stakes are highest.
What the dispute actually costs
The cost is not the amount refunded. It bills you from three directions:
- Support time. These tickets do not close on the first line. Nobody can answer without looking at the data, and the person who can look at it is usually an engineer.
- Arbitrary decisions. When the data does not answer cleanly, the decision becomes policy: sometimes you refund, sometimes you do not. Users talk to each other, and the perception that becomes "if you push hard enough they pay" is expensive.
- Public complaints. Liquidation disputes do not stay private. They get posted with a screenshot — and the chart in that screenshot genuinely does not show the wick. It is a hard image to argue with.
What doing it properly costs
Approach B is not free. It carries two real prices:
- Write volume. Storing 1-minute candles continuously for every market is far more data than storing sparse timeframes. We use TimescaleDB; being purpose-built for time series, it carries that load considerably better than an ordinary relational table.
- Derivation cost. Higher timeframes are computed on request, which is more expensive than reading a pre-stored candle. It needs caching, and the cache has to invalidate at exactly the right moment.
What you get in return is not technical elegance. It is defensibility. When a user or a regulator asks what this liquidation was based on, the answer points at one record, and every chart derived from that record confirms it.
How to check your own platform
You can run this test on a platform you use or are evaluating:
- Pick a market that moved sharply in the last 24 hours.
- On the 1-minute chart, find the most extreme wick; note its exact time and price.
- Look at the same moment on the 5-minute chart, then the 15-minute.
- The high/low of the higher timeframes must contain the wick from the lower one.
If it does not, your timeframes are independently sourced — and one day you will face a dispute you cannot win.
The question to ask a vendor
"Where does your candle data come from?" almost always gets "from exchange data", which tells you nothing. The concrete question is: "Which timeframe is authoritative, and how are the others produced?" If the answer does not name a timeframe, they are probably all arriving separately.
How we do it
In iExchange only the 1-minute base candle is independently sourced; every timeframe above it is derived mathematically from it inside TimescaleDB. That turns a liquidation dispute from an argument into a verifiable question — support can show the user the same data and reach the same conclusion.
This alone does not make an exchange good, and we would not claim otherwise. But it removes the most common way an exchange loses trust, and decisions like this cannot be revisited later — candle architecture is among the hardest layers to migrate once it is in place.
If you are planning to launch an exchange
This is one of the decisions that has to be made early in the architecture. Whatever stage your plan is at, let's talk — and if your liquidity plan is not ready, we will say so plainly.