Treasury analysts managing digital asset portfolios routinely face a question with no clean answer: when should we execute a rebalance on-chain through a DEX, and when should we use a centralized exchange? The obvious factors are fee structures and counterparty relationships. The less obvious factor, and the one that often determines the actual execution outcome, is how to compare liquidity depth between two structurally different venue types.
CEX order books and DEX liquidity pools are not directly comparable. An order book at 0.5% spread has different depth characteristics than a concentrated liquidity AMM at an equivalent price impact. Treasury teams that compare these venues only on fee schedules and quoted prices are missing the liquidity dimension, which is the variable that matters most for larger transaction sizes.
The measurement translation problem
On a centralized exchange order book, depth is represented as aggregate resting orders at each price level. To know how much you can buy before the price moves by 1%, you sum all the resting sell orders between the current best ask and 1% above it. This is a static snapshot of declared liquidity: the orders that are currently in the book.
On a DEX AMM pool, depth is a function of the pool's reserve ratio and curve type. For a constant-product pool, depth at 1% is the amount you can swap before the price (ratio of reserves) moves by 1%. For a concentrated liquidity pool, it depends on how much active liquidity is sitting within 1% of the current price. Neither of these is directly comparable to order book depth without a translation step.
The translation is straightforward in concept: convert both to "dollars available within X% price impact." For a CEX order book, sum orders within X% of mid. For a DEX pool, compute the swap size that moves the pool price by X%. The units are now the same and you can compare them directly. The complication is that the CEX snapshot and the DEX snapshot need to be taken at the same time to be meaningful, and the reliability of each source is different.
Why the comparison is biased toward CEX in standard analysis
Most treasury teams comparing CEX versus on-chain execution are working with data that underestimates on-chain depth in several systematic ways. The first is stale data: DEX pool depth is commonly accessed through block explorer exports or aggregator APIs that are cached on varying schedules, while CEX order book data is typically fresher. A stale DEX depth estimate from two hours ago during a quiet period will understate current depth if LP inflows have been positive, or overstate it if there was significant directional volume in the interim.
The second bias is pool selection. Most standard analyses compare CEX depth to a single DEX pool. In practice, for any major token pair, there are multiple DEX pools across multiple chains and protocols. The correct comparison is CEX versus the best achievable on-chain execution, which requires knowing the depth across all relevant pools and routing options. A treasury team looking only at the primary Osmosis DEX pool for ATOM-USDC is missing the depth available via multi-hop routes or cross-chain paths that can sometimes offer better aggregate depth for large transactions.
The third bias is fee accounting. CEX execution has explicit fees (maker-taker schedules, varying by tier). DEX execution has swap fees (0.01-0.3% depending on pool), plus gas, plus any bridge cost if cross-chain. The comparison is often done at the fee level without accounting for the fact that large on-chain swaps also incur slippage costs that are not present in the quoted fee. The combined cost for on-chain execution at large notional is: swap fee + slippage. Only including swap fee makes on-chain look artificially cheap.
A framework for the actual comparison
The framework we use for treasury execution analysis has four components. First, define the notional range: what is the smallest and largest transaction size you need to execute for this rebalance? A framework calibrated for $50k trades does not apply to $500k trades.
Second, measure both venues at execution size. For CEX, compute available depth within your target price impact threshold by summing resting orders. For DEX, compute the expected slippage at your transaction notional using the current pool state. Express both as all-in cost per dollar transacted: fees plus estimated slippage, at your target notional size.
Third, account for execution certainty. CEX execution is contingent on order fill (limit orders may not execute, market orders at large size may experience partial fills at worse prices). On-chain execution is deterministic within the slippage parameters you set, but subject to front-running and MEV on transparent mempools. The certainty characteristics are different and matter for time-sensitive rebalances.
Fourth, account for counterparty exposure duration. CEX execution requires holding assets on a centralized platform from the time of deposit to the time of withdrawal. For treasury teams with custody policies, this represents a period of counterparty risk. On-chain execution has no such interval. This is not always a decisive factor, but for treasury policies with strict custodial requirements, it changes the true cost comparison.
Where on-chain is consistently more attractive
For Cosmos-native assets with significant liquidity on Osmosis DEX (ATOM, OSMO, and the major IBC tokens), on-chain execution is often competitive with CEX for moderate transaction sizes, typically in the $10k-$100k range per transaction. At these sizes, the slippage on a well-capitalized DEX pool is comparable to the CEX spread-plus-fee for a mid-tier account, and the absence of CEX counterparty exposure is a genuine advantage.
For large transactions above $250k-$500k on a single pool, CEX generally has better depth for major pairs. The order book depth at major venues for established pairs like BTC-USDT or ETH-USDC is substantially deeper than any single DEX pool at current liquidity levels. On-chain becomes more competitive again when the transaction can be split across multiple pools or chains and executed with routing logic, which distributes the price impact.
For assets that are primarily on-chain or Cosmos-native with limited CEX representation, on-chain is often the only practical option regardless of size. In these cases, the relevant comparison shifts to quality of on-chain routing rather than CEX versus DEX.
What treasury teams need from their data stack
The practical implication for data infrastructure is that treasury teams need both CEX order book depth and DEX pool depth, expressed in the same metric (available liquidity at price impact thresholds), updated on a cadence appropriate to their execution frequency. Comparing a live CEX order book against a weekly DEX depth snapshot is not a real comparison. Both data sources need to be fresh and measured consistently for the analysis to produce actionable recommendations rather than directional guesses.
The teams that get this right tend to build the comparison explicitly into their pre-trade analysis rather than relying on judgment built on stale venue impressions. The framework is not complicated once the data is available. The data availability is the hard part.