Every exchange reports trades.
Very few let you observe everything that happened before a trade actually occurred.
That's where Hyperliquid Level 4 (L4) data changes the picture.
Instead of exposing only completed transactions or aggregated order book snapshots, CoinAPI streams every order placement, modification, cancellation, rejection, partial fill, and execution directly from Hyperliquid's matching engine infrastructure. Combined with oracle prices, TWAP status updates, and raw exchange events, developers can finally study how liquidity behaves… not just where prices ended up.
One statistic immediately catches everyone's attention.
Only about 1.1% of submitted orders eventually become completed trades. Around 88% are rejected immediately, while almost all remaining orders are eventually canceled.
At first glance, those numbers look alarming.
They shouldn't.
In fact, if your exchange didn't behave this way, that would probably be the bigger concern.
The Wrong Metric
Many developers instinctively judge a market by its executions.
More trades.
More volume.
More liquidity.
But execution rate tells you surprisingly little about how an exchange actually functions.
Professional trading firms rarely ask:
How many orders executed?
Instead, they're interested in questions like:
- How long does liquidity survive?
- How quickly do quotes react to new information?
- How aggressively do market makers defend queue position?
- How stable is displayed liquidity?
- How often does liquidity disappear before price moves?
Those questions describe market quality.
Trade count simply describes market outcomes.
That's an important distinction.
Modern Order Books Are Continuous Negotiations
A common misconception is that an order book represents a collection of traders waiting patiently to buy and sell.
That may have been closer to reality years ago.
Today, most visible liquidity is managed by automated systems continuously adapting to new information.
Every market movement forces thousands of micro-decisions.
Should this quote move?
Should inventory be reduced?
Has another venue become more attractive?
Did volatility increase?
Has funding changed?
Should this order stay in the queue?
Every answer creates another order event.
Most of those events never become trades.
Instead, they become cancellations, amendments or entirely new orders.
In other words, the order book isn't a promise to trade.
It's a real-time expression of thousands of competing strategies trying to balance profitability against execution risk.
Looking at Trades Is Like Watching the Last Frame of a Movie
This is where many research projects unintentionally lose valuable information.
Suppose two markets produce exactly the same trade history.
Identical prices.
Identical volume.
Identical spreads.
At first glance, they appear interchangeable.
Until you examine what happened inside the matching engine.
| Metric | Market A | Market B |
| Average displayed depth | $18M | $18M |
| Spread | 2 ticks | 2 ticks |
| Daily volume | $620M | $620M |
| Average order lifetime | 35 ms | 920 ms |
| Cancellation intensity | Extremely high | Moderate |
| Queue turnover | Constant | Stable |
From a traditional market data perspective, these markets look identical.
From an execution perspective, they couldn't be more different.
Market A is constantly repricing liquidity.
Market B provides far more persistent quotes.
If you're building execution algorithms, those differences matter far more than the trade history itself.
Neither OHLCV candles nor aggregated order books can reveal them.
The Hidden Cost of Aggregation
Aggregation is incredibly useful.
It reduces bandwidth.
It simplifies visualization.
It makes order books easier to understand.
But aggregation also removes information.
Imagine seeing this update:
Bid @118,450
Size:
120 BTC
↓
95 BTC
Several explanations are possible.
One participant canceled 25 BTC.
Five participants each canceled 5 BTC.
Some liquidity executed.
Several new orders entered while others disappeared.
The exchange reprioritized the queue.
From an aggregated Level 2 feed, every scenario produces the same result.
The information that distinguishes them has already been discarded.
That's why many advanced analytics simply cannot be built from aggregated market data.
The problem isn't insufficient processing.
The underlying information no longer exists.
What Level 4 Actually Adds
Level 4 doesn't just increase the amount of data.
It changes the questions you can ask.
Instead of observing price levels, you observe individual orders.
Instead of watching snapshots, you watch state transitions.
Instead of estimating behavior statistically, you measure it directly.
Some examples include:
| Traditional Feed | Hyperliquid 4 |
| Current book depth | Every order lifecycle |
| Aggregated liquidity | Individual orders |
| Trade executions | Placements, modifications, rejections, cancellations and executions |
| Anonymous orders | Wallet attribution |
| Current state | Complete market evolution |
That's a fundamentally different dataset.
It's no longer about reconstructing what probably happened.
It's about observing what actually happened.
Why Rejections Matter More Than Most Developers Think
Order rejections are often dismissed as operational noise.
They're anything but.
On Hyperliquid, many liquidity providers use Add Liquidity Only (ALO) instructions.
If an order would immediately execute as a taker, the exchange rejects it instead.
That rejection isn't a failure.
It's confirmation that the strategy successfully avoided taking liquidity.
Other rejections happen because market conditions changed before the order reached the matching engine.
Some occur because another participant updated first.
Others reflect changing inventory limits or evolving risk constraints.
Each rejection tells you something about the environment the trading algorithm was operating in.
Taken individually, they seem insignificant.
Taken together, they reveal how competitive the market really is.
And that's something trade data alone can never show.
Cancellation Rate Is More Interesting Than Fill Rate
Most dashboards celebrate executions.
Executions generate volume, fees, and price discovery.
But if you're trying to understand how a market behaves, cancellations often contain much richer information.
Think about what has to happen before an order is canceled.
A trading algorithm has already:
- evaluated current market conditions
- calculated inventory risk
- estimated adverse selection
- compared prices across venues
- decided that keeping the order active is no longer optimal
A cancellation is rarely random.
It's the output of a decision-making process.
That's why professional trading firms often monitor cancellation intensity alongside traditional liquidity metrics.
A sudden wave of cancellations can indicate:
- liquidity providers pulling risk
- increasing market uncertainty
- growing competition at the best bid or offer
- preparation for higher volatility
None of those signals appear in OHLCV data.
Most don't even appear in traditional order book snapshots.
Order Lifetime Reveals Liquidity Quality
Displayed liquidity can be misleading.
Two markets may show exactly the same depth, yet offer completely different execution quality.
The difference often comes down to how long orders remain in the book.
| Average Order Lifetime | What It Usually Suggests |
| <50 ms | Extremely competitive quoting, rapid repricing, HFT-dominated environment |
| 50–500 ms | Active market making with continuous quote adjustments |
| 500 ms–2 s | Relatively stable liquidity and lower queue turnover |
| Several seconds | Passive liquidity with less aggressive repricing |
Order lifetime isn't a universal measure of market quality.
Context always matters.
But it provides something that displayed depth cannot:
confidence in available liquidity.
A book showing $20 million of depth means very little if most of those orders disappear before anyone can interact with them.
Queue Position Is a Competitive Advantage
For many quantitative strategies, execution isn't determined by price.
It's determined by queue position.
Being first at the best bid may dramatically increase execution probability.
Being tenth might reduce it to nearly zero.
Without individual order identifiers, measuring queue dynamics becomes almost impossible.
With Level 4 data, researchers can analyze:
- queue growth over time
- queue depletion after aggressive trades
- position loss caused by order amendments
- execution probability by queue depth
- expected waiting time before a fill
These metrics are fundamental for market-making models, execution algorithms, and transaction cost analysis.
They're also impossible to calculate from aggregated order book feeds.
What Advanced Teams Actually Measure
One of the biggest differences between retail analytics and institutional research is the choice of metrics.
Rather than focusing on trades alone, quantitative teams often build models around the behavior of liquidity itself.
| Traditional Analytics | Advanced L4 Analytics |
| Trade Volume | Cancellation intensity |
| Spread | Quote persistence |
| Daily volatility | Queue turnover |
| VWAP | Liquidity replenishment speed |
| Best bid/ask | Order lifetime distribution |
| Price movement | Maker behavior by wallet |
Notice that very few of these metrics depend on completed trades.
Instead, they measure the dynamics of the matching engine.
That's where execution quality is created… or lost.
The Orders That Never Execute Still Tell a Story
One of the biggest advantages of Hyperliquid L4 is wallet attribution.
Instead of anonymous liquidity, every passive order and every executed trade includes the associated public wallet address. Combined with persistent order identifiers, this makes it possible to study participant behavior over time rather than treating every event as isolated.
For example, researchers can identify wallets that:
- constantly refresh quotes without seeking execution
- aggressively defend queue position
- consistently withdraw liquidity before volatility spikes
- rely heavily on TWAP execution
- provide stable liquidity across multiple trading sessions
The interesting observation isn't necessarily who those participants are.
It's how they behave.
Patterns often emerge long before they become visible in price action.
Beyond the Order Book
CoinAPI doesn't stop at book_l4.
Hyperliquid data is delivered through six complementary feed families that expose different parts of the market.
| Feed | What It Adds |
| book_l4 | Complete order lifecycle and queue evolution |
| trade_l4 | Executed trades with maker and taker wallet attribution |
| hl_oracle_prices | Mark prices, oracle prices, external inputs and daily references |
| hl_twap_statuses | TWAP lifecycle, execution progress and completion status |
| hl_misc_events | Raw exchange events for observability and custom processing |
| hl_system_events | System-level actions linked to block metadata |
Together, these feeds allow developers to move beyond traditional order book analysis.
You can correlate changes in oracle prices with liquidity withdrawals, measure TWAP execution quality, investigate how raw exchange events affect queue dynamics, or combine multiple streams into a richer execution model. All six feeds are available through a single WebSocket DS connection, with aligned historical Flat Files for replay and backtesting.
A Better Way to Think About Market Activity
The statistic that only about 1.1% of submitted orders become completed trades often surprises people.
But maybe the more interesting conclusion is this:
Markets aren't primarily made up of trades.
They're made up of decisions.
Every order placement, every cancellation, every amendment, every rejection reflects a participant reacting to new information, changing risk, or competing for queue position.
Trades are simply the moments when two of those decisions happen to meet.
If you only analyze executions, you're studying the outcome.
If you analyze the full order lifecycle, you're studying the process that produced the outcome.
For advanced quantitative research, execution modeling, and market microstructure analysis, that difference is enormous.
Understand the Market Before the Trade
The most valuable information in a modern electronic market often disappears before a trade is ever printed. That's why CoinAPI streams Hyperliquid Level 4 data as raw, unaggregated order events instead of waiting for block-level summaries or reducing activity to snapshots.
Through a single WebSocket DS connection, you can access complete order lifecycles, executed trades with wallet attribution, oracle price updates, TWAP status streams, and raw exchange events in real time.
The same datasets are available as historical Flat Files with aligned schemas, allowing you to build, test, replay, and deploy strategies without changing your data model.
Whether you're building market-making infrastructure, execution algorithms, surveillance systems, or quantitative research pipelines, Hyperliquid L4 gives you the data needed to understand why the market moved… not just where it moved next.
Explore Hyperliquid L4 Data and unlock the full order lifecycle.
👉 Get Your API Key and Start with Free Credits
Related Topics
- What Is Level 4 (L4) Order Book Data?
- CoinAPI Introduces Hyperliquid L4 Data
- Tracking the Whales: Using Hyperliquid L4 Wallet Data for an Edge
- Building a Reproducible Hyperliquid Order Book Replay from CoinAPI Book L4 Flat Files
- What Data Is Available Through CoinAPI WebSocket DS for Hyperliquid?
- Demystifying Level 4 (L4) Order Book Data: Why Waiting for Block Confirmations Is Dead on Arrival
