Lecture 2: Liquidity Measures
A practical series for the discerning retail trader and the quantitative alchemist on Market Microstructure
đŻïžGreetings, esteemed reader!
In the previous lecture, we outlined robust Normalized Realized and Effective Bid-Ask Spread measures that work pretty well in practice, especially in HFT (overall, the higher the frequency, the more sense the spread makes).
In this second lecture of Zero Lag Clubâs Market Microstructure series, we dive into measuring liquidity in practice on centralized limit order book (CLOB) exchanges.
Building on the foundations of Spread (Lecture 1), weâll explore how quants and traders actually gauge liquidity using both theoretical models đŹ and practical metrics đ ïž. The focus here is strictly on order-book markets â AMMs will be covered later (their liquidity is defined by explicit curves, a topic for another scroll).
The lecture is pretty extensive (Iâd schedule 1 hr to study it), but I promise it contains only necessary information for understanding the further material and building trading models.
Markers
đŹ : theory-heavy concepts useful for context (less directly monetizable).
đ ïž : hands-on code, heuristics, or practical tips.
Required Knowledge
Basic orderâbook vocabulary, high-school math, and a bit of Python/pandas for examples will help. If your curiosity pendulum swings into deeper research, check the references at the end, as usual.
Outcome
Youâll get a working toolkit to measure liquidity and understand which metrics matter:
Theoretical Models: Rollâs implied spread, Kyle & Obizhaevaâs impact invariance, Hasbrouckâs lambda (price impact).
Practical Metrics: Amihudâs illiquidity, VWAP, and slippage, Implementation Shortfall, Realized Spread.
Low-Frequency Proxies: Daily spread estimators (CorwinâSchultz, AbdiâRanaldo) and others validated for crypto by recent research.
Use Cases: Which measures are production-grade for crypto trading vs. which are academic or obsolete?
Liquidity Measures đ§Ș
Theoretical Foundations of Liquidity Costs
Rollâs Model (1984) â Implied Bid/Ask Spread
Kyleâs Lambda and Square-Root Impact
Price Impact vs. Cost: Temporary and Permanent
Practical Liquidity Measures
Amihudâs Illiquidity (2002)
Volume-Weighted Average Price (VWAP) and Slippage
Implementation Shortfall (IS)
Realized Spread
Low-Frequency Liquidity Proxies
CorwinâSchultz estimator (2012)
AbdiâRanaldo estimator (2017)
Production usage
đ„ Shall we commence?
Letâs start by mapping the theoretical foundations of liquidity costs, then roll up our sleeves for practical measures with some code-ready insights.
Again, canât avoid theory, understanding classic models gives context to why specific liquidity measures work (or donât) in crypto.
đŹ Theoretical Foundations of Liquidity Costs
Rollâs Model (1984) â Implied Bid/Ask Spread
One elegant idea by Richard Roll (1984) derives the effective spread from price time series alone. Measuring the bid-ask spread when only the price is known - sounds like magic! I believe earlier it was a highly useful solution when it was impossible or hard/expensive to get real orderbook data. Nowadays, the case is very different - the real-time feeds are available for free from the exchange, historical orderbooks can be relatively expensive but available, and hardware is cheap enough to handle all the tick data volume required.
Despite the 40 years of history, the model remains indispensable in modern quant finance, and it is still actively used, and shows good results in crypto as well (20bps error average and 50bps in volatile regimes), Iâd see it primarily use is backtesting, because when itâs hard (or expensive) to get historical orderbook for an asset.
So, Roll observed that in an efficient market (with true value static short-term), alternating buys and sells cause negative autocorrelation in price changes â prices zigzag as trades flip between bid and ask. This means that the covariance of successive price changes, Cov(Îpt,Îptâ1), would be negative, and its magnitude is related to the bid-ask spread. In simple words, this means that if the price goes up in the previous period t-1, it will go up in the current period t, and vice versa.
Rollâs formula for spread (in its simplest form) is:
Assuming that the covariance is negative. Intuitively, if prices tend to revert by a small amount each trade, that amount is about the half-spread.
This basically says: the more the price bounces back and forth, the wider the spread must be.
The model makes lots of assumptions, the main of which are that bid-ask is mean-reverting (tx prices oscillate between bid and ask quotes) and thereâs no serial correlation in trades: trade signs (buy/sell) are independent (no clustering of buys or sells).
Formally, the assumptions are as follows:
All trades have the same size. Trade direction d=1 is a buy, d=-1 is a sell.
Arriving orders are i.i.d. (identically independently distributed):
\(\mathbb{P}(d_t=1) = \mathbb{P}(d_t=-1) = \frac{1}{2}\)Midquote follows a random walk. If m is a midprice and Δ - some innovation term, a i.i.d. price shock, then
\(m_t = m_{t-1} + \epsilon_t\)Market orders are not informative. This is somewhat the most questionable assumption, since a direction d in the next period doesnât depend on how the price moved. Expectation of how the quote has moved equals to how it will move and itâs zero.
\(\mathbb{E}(d_t \epsilon_t) = \mathbb{E}(d_t \epsilon_{t+1}) = 0\)Spread is constant.
\(S = a_t - b_t\)
Letâs derive the Rollâs model now!
The price is midquote with the halfspread times the direction of the trade:
We know p, but not m. How to estimate S?
The key (and very neat!) idea of the Rollâs paper is the mean revertion of the price and direction of the trade, prices are pressured to return to the midquote:
Itâs simple to understand it intuitively, if Îdt> 0 that means that we go from a sale to buy, and the next change Îdt+1 should be the opposite.
Now, since Cov is a linear operator, itâs just a variance of dt-1
Thus
Which gives us the estimator
These pricesâ covariances can be computed from the price data.
Thatâs it!
đŹ Why it fails in crypto: crypto prices are trending very often and exhibit momentum (positive autocorrelation) very often, rather than mean-reversion at trade-to-trade frequency. In trending markets, Rollâs negative covariance assumption breaks down which breaks down the whole thing â you might get a positive or near-zero covariance, leading to a zero or undefined implied spread. In practice, Rollâs estimator often outputs zero for crypto assets. The modelâs spherical-cow assumptions listed above rarely hold on volatile crypto markets.
I might clean up the code I have that tests the measure for the Binance feed and share it with you in a separate post. In short, itâs heavily off, but itâs not that bad for HFT, where trends and momentum are not that significant. In most cases, it underestimates liquidity costs in crypto.
Rollâs measure is still a cornerstone of the microstructure theory, and the idea that the effective spread can be backed out from price dynamics is just cool.
Kyleâs Lambda and Square-Root Impact
Kyle (1985) introduced the concept of lambda (λ) as the price impact per unit size in his insider trading model. In Kyleâs model, trades move the price linearly: Îp=λâ q+noise, where q is the signed trade size. Lambda reflects adverse selection costs â a larger λ means the assetâs price moves more when someone tries to buy/sell a given amount (low liquidity).
In practice, we can estimate Kyleâs lambda by regressing price changes on signed volume or order flow. For example, over many trades:
where mt is the midprice, dtâ{+1,â1} the trade direction (buy or sell), and Vt the trade size (perhaps in USD). The slope λ is an empirical price-impact metric (e.g., â$0.05 price move per 1 BTC tradedâ). Hasbrouckâs model (1991) is a close cousin: it uses a vector autoregression of trades and quotes to measure the information content of trades, yielding a similar notion of price impact (often also dubbed lambda). These regression-based lambdas are useful in research to compare assets or time periods. However, they can be noisy and require high-frequency data. A few crypto trading shops estimate Hasbrouckâs VAR in real-time. Instead, itâs often better to use simpler stats (like immediate slippage or beta to order flow) for on-the-fly impact tracking.
đ ïž Code Tip: You can estimate a simple lambda in Python by fitting a line:
price_diff ~ sign * volume
. Use trade tape data or one-minute bars. The R-squared will be low, but λâs magnitude gives a ballpark of impact. Calibrate in basis points per $1M traded, for instance.
Now, empirical studies found Kyleâs linear model is too simplistic for large trades. Large meta-orders (series of trades) tend to have a nonlinear impact.
A famous result is the square-root impact law:
Obizhaeva & Wang (2013) and Kyle & Obizhaeva (2016) formalized this via market microstructure invariance theory. Without diving into dimensional analysis, the takeaway is that impact grows sub-linearly with size â doubling the trade size doesnât double the impact, it increases by less (roughly â2). This is why slicing orders (âicebergingâ) makes sense: ten 100 ETH buys throughout the day move the price less overall than one big 1000 ETH buy.
For us practitioners, the square-root law suggests using concave impact models for cost estimation. Many execution algos (TWAP, POV, etc.) implicitly assume this concavity. In crypto, the square-root law holds qualitatively, although the exact coefficient varies by asset and venue liquidity.
Price Impact vs. Cost: Temporary and Permanent
Not all price impact is permanent. Hasbrouckâs price impact can be thought of as the permanent price change resulting from information (e.g., informed trading). The remainder of the spread/impact is temporary (due to inventory pressure or bounce). Realized Spread vs Price Impact is a helpful distinction:
Price Impact (per Hasbrouck or others) measures how far the price stays moved after a trade.
Realized Spread measures the part of the spread captured by liquidity providers, i.e. the profit of a market maker if the price mean-reverts.
Weâll cover realized spread more shortly â itâs a resiliency metric (how quickly prices revert) - remember liquidity dimensions from the Spread lecture.
đŹ Bottom line: Theoretical models give us λ (lambda) and other intuition pumps. But to actually measure liquidity on crypto exchanges, we need practical formulas. Letâs now turn to hands-on liquidity measures you can compute from data.
đ ïž Practical Liquidity Measures
The following metrics are the bread-and-butter tools to quantify liquidity and trading costs on CLOBs. You can implement these with exchange data using any language with relative ease.
Amihudâs Illiquidity Ratio (2002)
One widely used measure in academia (and increasingly in crypto quant circles) is the Amihud Illiquidity Ratio. Proposed by Yakov Amihud, it captures the idea of price impact per volume. For a given day d, itâs defined as:
where R is the assetâs return (usually absolute return, in decimal) and Vol is the trading volume in dollar terms that day. If you average this across days in a period, you get an estimate of how much the price moves per unit of trading volume. A low Amihud value means high liquidity (you can push a lot of volume for little price change), while a high value means illiquidity.
Usage: Amihudâs metric is great for comparing assets or exchanges cross-sectionally. Brauneis et al. (2021) found that Amihudâs ratio, despite being simple, does well in ranking the liquidity levels of different crypto exchanges. For example, if Exchange Aâs BTCUSD has half the Amihud value of Exchange Bâs, A generally offers a tighter market with less slippage per trade dollar.
đ ïž Code Tip: Given daily OHLCV data, you can compute
amihud = (abs(return) / dollar_volume).resample('D').mean()
in Python. Make sure to use dollar volume (price * quantity) for consistency. Watch out for outliers on days of huge returns but low volume â consider median or winsorizing in those cases.
However, note that Amihud is less useful for time-series liquidity changes. In fast-moving markets, volume and volatility can spike together, making daily illiquidity noisy. For intraday use, a rolling version can be computed (e.g., hourly illiquidity); however, many practitioners prefer direct order book statistics intraday.
Volume-Weighted Average Price (VWAP) and Slippage
VWAP â Volume Weighted Average Price â is technically a benchmark price, not a liquidity metric in itself. But itâs crucial in execution. Traders commonly gauge slippage by how far their execution price is from the VWAP over the execution interval.
For example, say you need to buy 50 BTC over 10 minutes. The marketâs VWAP in that 10-minute window (considering all trades) was $30,000. If your average execution price ended up $30,100, then you paid 0.33% above VWAP. That difference is slippage cost â a measure of liquidity immediacy and market impact during your execution.
VWAP is used as a benchmark for immediacy because an uninformed execution spread evenly in time should approximately achieve VWAP (assuming youâre a small part of the volume). If you trade too aggressively (demanding immediacy), youâll push the price and end up worse than VWAP; if you trade too passively or slowly, you might chase a drifting price and also miss VWAP. Thus, VWAP is the bar to beat.
đ ïž Practical Use: Many crypto execution algos (TWAP, VWAP algos) aim to track or beat VWAP. As a trader, you measure execution performance as Implementation Shortfall (next section) or vs VWAP. Exchanges donât give VWAP directly, but you can compute it from trades. In Python, given trades with price and size,
vwap_price = (price * size).sum() / size.sum()
for the interval.
Implementation Shortfall (IS)
The Implementation Shortfall is the Tradfi-s gold-standard metric for total trading cost which is adopted by crypto. Originally coined by André Perold (1988), IS is the difference between the paper price when you decide to trade and the actual average price you get. It captures both spread and market impact (and timing delays). It was used to measure the performance of a broker.
Letâs break it down: You decide to buy at 10:00 when the midprice is $100. By the time your order fully executes, you ended up paying an average price of $101. Meanwhile, the market mid moved to $100.5 during your execution (maybe due to other traders or your own impact). Your implementation shortfall can be decomposed as:
Spread cost: If you crossed the spread to buy, maybe half the spread (say $0.1) was lost right away.
Impact/timing cost: The mid moved up $0.5 while you were executing â thatâs adverse movement against you.
Opportunity cost: If you didnât complete the full order, any unfilled part has an implicit cost if price keeps rising.
In total, your IS = $101 â $100 = $1 (1%) on that trade. This is the real cost of trading beyond the ideal scenario. Itâs crucial for algorithmic execution evaluation â you want to minimize IS.
Formally, one can write Implementation Shortfall for a buy order as:
where Pdecision is the price (mid or last) when the trading decision was made (or a benchmark like previous close), and Pavgâfill â is the volume-weighted execution price. For sells, the formula is analogous (you want to sell high; any average fill below decision price is cost).
đ ïž Code-Level Tip: To compute IS, you need to record a benchmark price at the start (decision time or arrival price). Then track all fills of the order and compute the size-weighted average fill price. The difference (with correct sign) is your IS. If working with historical data, you can simulate an execution (e.g., splitting into chunks) and compare with a baseline price path. Pythonâs pandas can help aggregate fills; just be careful to align timestamps for the benchmark price.
Implementation Shortfall vs VWAP: If you use VWAP of the period as your benchmark, that variant is often called VWAP slippage. For example, some traders say âWe were 5 bps inside VWAPâ meaning they beat the VWAP by 0.05% (a positive outcome). This is essentially a flavor of implementation shortfall using VWAP as the benchmark instead of the decision price.
Realized Spread
In Lecture on Spread we introduced Realized Spread (RS) â a metric particularly relevant for market makers and liquidity providers. While effective spread measures the cost paid by takers on a given trade (difference between trade price and midprice at that moment), the realized spread looks ahead: itâs the difference between the trade price and the midprice after some time Î.
If I sell to a market maker at $100 (mid was $99.9, so effective spread paid ~$0.1), and 5 minutes later the midprice is $99.8, the market maker benefited â they sold higher than the new mid. The realized spread for that trade to the market maker is $100 â $99.8 = $0.2.
Conversely, if the mid jumps to $100.5 after, the market makerâs gain from the spread was eroded (negative realized spread, meaning the takerâs trade had information).
Mathematically, for a buy order (taker perspective, d=+1 for buy, â1 for sell):
Realized Spreadt,
where pt is the trade price and mt+Î â the midprice Î time later. The choice of Î (e.g. 1 minute, 5 minutes) is critical â too short and itâs mostly noise, too long and other factors move the price.
For a liquidity taker, a small realized spread (or negative) means you implicitly didnât pay much extra beyond the true price impact. For a market maker, a large positive realized spread means you earned your quoted spread and the price didnât run away on you â a good trade. Realized spread thus measures resiliency of the market: how quickly prices mean-revert after trades. A resilient market where liquidity replenishes quickly tends to have lower permanent impact (and higher realized spread for makers).
đ ïž How to estimate: Using trade and quote data, for each trade record the midprice some minutes later. Compute d(pâmfuture) and average over many trades (you might condition on trade size or time of day). In Python, you can do this by merging the trade tape with a delayed midprice series. This helps quantify how much of the spread is ârealâ vs just temporary. Low realized spread (relative to effective spread) means information-heavy trades (price moved against the maker), whereas high realized spread means mostly noise or inventory trading.
Low-Frequency Liquidity Proxies
Thus far, we discussed measures youâd compute if you have tick-level data. What if you only have daily or hourly bars? Thatâs not our typical trading case though - we usually operate hft or mid-frequency (minutes). But in some cases, you need that data - for example, in mid-low frequency strategies like funding arbitrage, you want to know what venues to trade if there are the same assets with almost the same funding rates, but the liquidity differs. There are clever spread estimators that use low-frequency data to infer liquidity. Interestingly, some of these have been tested on crypto and work quite well. Here are two notable ones:
CorwinâSchultz estimator (2012): Uses daily high and low prices to estimate the bid-ask spread. The intuition: high prices are usually buyer-initiated trades and lows are seller-initiated, so the ratio of highs/lows over two days contains information about the spread. The formula is a bit involved (it uses the difference between single-day and two-day ranges to back out the spread). Corwin-Schultz is cheap to compute â you just need High and Low for two days, making it handy for quick comparisons. Brauneis et al. (2021) found this estimator excels at tracking time-series liquidity changes in BTC and ETH markets. That means if liquidity is drying up, the C-S measure will rise, and vice versa, roughly in sync with true spreads.
AbdiâRanaldo estimator (2017): An improvement over C-S, this uses Close, High, and Low prices to estimate spreadsaeaweb.org. Itâs also designed for daily data but tends to be more accurate by incorporating closing price information (reducing bias from day gaps). AbdiâRanaldo also performed very well in crypto, slightly outdoing C-S in some cases. If you have daily OHLC, this is a great proxy for average bid-ask spreads without needing tick data.
Both of these give an estimated percentage spread. For example, AbdiâRanaldo might estimate that an exchangeâs typical spread is 0.20%. They wonât capture depth or large-order costs, but they reflect top-of-book tightness over time.
Other proxies include âNumber of Tradesâ or Dollar Volume (more volume often means more liquidity) and variants of high-low volatility measures. Brauneis et al. tested a bunch. Two highlights from their findings worth noting:
For time-series liquidity (dynamic changes): Corwin-Schultz and Abdi-Ranaldo were the best, indicating these high-low based measures track liquidity over time better than, say, Amihud or trade counts. This is likely because high-low ranges widen when volatility and trading costs spike, signaling illiquidity in turbulent times.
For cross-sectional and level estimates: Amihudâs illiquidity and a proxy from Kyle & Obizhaeva (2016) invariance were most reliable. The âKyle-Obizhaeva estimatorâ they used is rooted in invariance theory â it scales volume and volatility to produce a liquidity metric (think of it as a predicted impact cost per trade). Those two measures were best at ranking exchanges by liquidity and even approximating absolute spread levels. So if you want to know which exchange is most liquid or whatâs the typical cost on Exchange X vs Y, Amihud and invariance-based metrics give a good gauge.
đŹ Reality check: Low-frequency proxies are great for research and monitoring broad trends or doing comparative studies when tick data isnât available. But if you do have order book data, youâll always get a more precise read from direct measures (actual quoted spreads, depth, etc.). Use proxies when you must (e.g. analyzing hundreds of altcoins quickly, or historical periods where only daily data exists).
Which Metrics Matter in Production?
Letâs summarize from a practitionerâs perspective â what should you actually use when trading crypto?
Quoted Spread and Order Book Depth: These are still king for real-time decisions. A tight normalized spread and substantial depth at the top of book mean you can execute small trades cheap. For larger trades, look at impact â e.g., how much the price moves if you sweep X dollars of the book (we covered weighted spreads in Lecture 1 and will delve more into slippage in future). These are immediately usable via exchange APIs.
Implementation Shortfall: If youâre executing large orders or running an algorithm, track IS on each order or day. Itâs the true bottom-line cost including all slippage. In a live trading system, youâd log the decision price and fills to compute this. If your IS starts creeping up, it might indicate deteriorating liquidity or an execution problem.
VWAP Slippage: This is often used in TCA (Transaction Cost Analysis) reports. Institutional traders will report âWe executed at 5 bps worse than VWAPâ for example. If youâre building execution algos, minimizing VWAP slippage (or beating VWAP) is a concrete goal.
Amihud Ratio: For strategy research or asset selection, Amihudâs illiquidity is handy to rank assets by liquidity. Itâs simple to compute and has intuitive units (percent move per $ traded). Itâs not something youâd compute intraday for signals, but good for filtering out illiquid coins or deciding how to allocate capital across venues.
Hasbrouckâs Lambda / Kyleâs Lambda: In high-frequency strategy dev, you might estimate these to understand impact. For example, if lambda for a coin is huge, you know even small trades will move it â be careful with order sizing. But these are diagnostic; we donât plug Hasbrouckâs VAR into a live system due to complexity and noise. Instead, simpler real-time estimators (like moving average of effective cost per trade size) are preferred.
Rollâs Measure: Honestly, pretty obsolete for crypto. Itâs elegant for teaching and for some stock datasets, but as we emphasized, it often gives false signals in crypto markets. Use it only if you suspect purely random trade directions and want a quick guess of spread â and be ready for it to output zero when thereâs persistent trending.
Corwin-Schultz / Abdi-Ranaldo: These are great for analysis â e.g., if youâre writing a report on historical liquidity or canât pull tick data for years of history. They arenât something a trading algorithm would use on the fly (theyâre too laggy and coarse for that). Think of them as research tools or for monitoring market health over time. For instance, you could plot a 30-day moving average of C-S estimator to visualize how an exchangeâs liquidity is improving or worsening.
In crypto markets, latency and explicit order book info reign supreme. We have full Level-2 data available, unlike some traditional markets where proxies were invented due to data scarcity. This means our production-grade metrics lean toward direct measurements (spreads, depth, fill stats). However, the theoretical concepts and low-frequency proxies are still invaluable for validation and understanding. They can validate if your direct measures make sense, or help compare liquidity across venues without streaming all their data.
As a final note, we deliberately left out Automated Market Makers here. AMMs (like Uniswap) have explicit liquidity curves and different metrics (like pool depth, k-values, etc.), which deserve their own discussion. Fear not â we shall tackle AMM liquidity in a later lecture.
For now, you should be equipped to measure and monitor liquidity on any crypto exchange with a limit order book. May your order placements be swift and your spreads ever tight!
See you in the next lecture, weâll start diving straight into market-making models.
References
Roll, R. (1984). A simple implicit measure of the effective bidâask spread in an efficient market. Journal of Finance, 39(4), 1127â1139.
Kyle, A. S. (1985). Continuous auctions and insider trading. Econometrica, 53(6), 1315â1335. (Introduced Kyleâs lambda)
Kyle, A. S., & Obizheva, A. A. (2016). Market Microstructure Invariance: Empirical Hypotheses. Econometrica, 84(4), 1345â1404. (Foundation of the square-root impact law)
Hasbrouck, J. (1991). Measuring the information content of stock trades. Journal of Finance, 46(1), 179â207.
Amihud, Y. (2002). Illiquidity and stock returns: cross-section and time-series effects. Journal of Financial Markets, 5(1), 31â56.
Perold, A. (1988). The Implementation Shortfall: Paper vs Reality. Journal of Portfolio Management, 14(3), 4â9.
Corwin, S. A., & Schultz, P. (2012). A simple way to estimate bid-ask spreads from daily high and low prices. Journal of Finance, 67(2), 719â759.
Abdi, F., & Ranaldo, A. (2017). A simple estimation of bid-ask spreads from daily close, high, and low prices. Review of Financial Studies, 30(12), 4437â4480.
Brauneis, A., Mestel, R., Riordan, R., & Theissen, E. (2021). How to measure the liquidity of cryptocurrency markets? Journal of Banking & Finance, 122, 106198.