How LiquidView Collects Execution Cost Data

The Problem: No Standard Execution Cost Metric Exists

Every DEX perpetual platform publishes its fee schedule. Most publish a live order book. But none of them publish the answer to the question that actually matters for trading decisions: "what will it cost me, in total, to execute a $25,000 market order on this exchange right now?" That number — combining fees, spread, and price impact into a single execution cost metric — does not exist anywhere in the data that exchanges expose. It has to be computed.

This gap exists because execution cost is inherently contextual. It depends on order size (larger orders pay more price impact), token (liquid pairs have lower execution costs than illiquid ones), and market conditions at the specific moment of execution (execution cost during a low-volatility Sunday night is very different from execution cost during a high-volatility event). No static number can capture this — only a continuously updated, multi-dimensional dataset can.

LiquidView was built to fill this gap. The platform collects execution cost data across all major DEX perpetual platforms, normalizes it to a consistent methodology, and makes it available through a structured API. Understanding how that collection process works — what is measured, when, how accurately — helps you use the data appropriately and understand its limitations.

LiquidView's Approach: Simulating Orders Across Exchanges Every 5 Minutes

The core of LiquidView's data collection is a continuous order simulation process. Every five minutes, LiquidView's collection infrastructure fetches a live order book snapshot from each tracked exchange for each tracked token pair. It then simulates executing market orders at a set of standardized size tiers against that snapshot: $1K, $5K, $10K, $25K, $50K, $100K, $250K, and $500K notional. For each simulated order at each size tier, it computes the all-in execution cost in basis points.

The five-minute collection frequency is a deliberate design choice that balances data freshness against infrastructure cost and rate limit compliance. Execution costs do change within a five-minute window during high-volatility events, but for the strategy-level decisions that most traders make — which exchange to use, whether current costs are elevated relative to normal — five-minute data is sufficiently fresh. Traders who need sub-minute precision for final execution timing can supplement LiquidView data with real-time order book feeds from their execution exchange.

• Collection frequency: Every 5 minutes per exchange per token pair.
• Size tiers measured: $1K, $5K, $10K, $25K, $50K, $100K, $250K, $500K notional.
• Cost components computed: Taker fee (from published fee schedule at standard taker tier), bid-ask spread (half-spread in basis points, measured from current best bid and ask), price impact (simulated order walk above half-spread).
• Total execution cost: fee_bps + spread_bps + impact_bps. Expressed as basis points of notional value for the given size tier.
• Data retention: Full historical dataset retained, enabling trend analysis and backtesting of routing strategies.

How Order Simulation Works: Walking the Order Book

Order book simulation is the technical core of the execution cost computation. The process models what happens when a trader submits a market order of a given size: the exchange matching engine fills the order by consuming available liquidity starting at the best price and moving progressively to worse prices until the full order is filled.

For a simulated buy order of size S: the simulation starts at the best ask price level, consuming as much quantity as is available at that level. If that quantity is insufficient to fill the full order, the simulation moves to the next ask price level and continues filling. This continues until the cumulative fill quantity reaches S. The simulated average fill price is the volume-weighted average of all the price levels consumed. Price impact is computed as the difference between this average fill price and the mid-price (the midpoint between best bid and best ask), expressed in basis points.

The spread component is computed separately from price impact. Half-spread is defined as (best_ask - mid_price) / mid_price * 10000 basis points. For a market buy, the trader immediately pays at least the half-spread by crossing from mid to ask. The price impact component measures any additional cost above the half-spread due to insufficient liquidity at the best ask level.

• Mid price: (best_bid + best_ask) / 2.
• Half-spread in bps: ((best_ask - mid) / mid) * 10000.
• Simulated fill price: Volume-weighted average fill price from order book walk.
• Price impact in bps: ((simulated_fill - best_ask) / mid) * 10000. (Cost above and beyond the initial crossing of the spread.)
• Fee in bps: Taker fee rate * 10000. (e.g., 0.025% taker fee = 2.5 bps.)
• Total execution cost in bps: fee_bps + half_spread_bps + price_impact_bps.

What Data Is Stored: Cost per Size per Token per Exchange

Each data collection cycle produces a structured record for every combination of exchange, token pair, and size tier. This record includes the timestamp of the order book snapshot used, the computed cost components (fee, spread, price impact), the total execution cost, and metadata fields (mid price at snapshot time, order book depth at the two closest ask levels, data collection latency).

This multi-dimensional dataset — organized along the dimensions of time, exchange, token, and size — is what enables the comparisons and analyses that LiquidView exposes through its API and interface. A query for "current execution cost for ETH at $50K" returns the most recent record from each exchange, enabling immediate cross-exchange comparison. A query for "historical execution cost trend for BTC at $25K on Hyperliquid" returns the time series of records for that specific (exchange, token, size) combination.

• Primary key: (timestamp, exchange, token_pair, size_usd).
• Fee component: fee_bps — the taker fee in basis points at standard taker tier.
• Spread component: spread_bps — half-spread in basis points at snapshot time.
• Impact component: impact_bps — price impact above half-spread for the simulated order.
• Total cost: total_cost_bps — sum of the three components.
• Supporting metadata: mid_price_usd, best_bid, best_ask, snapshot_latency_ms, collection_success (boolean).

The historical depth of this dataset grows over time and becomes increasingly valuable. Current data tells you today's costs. Historical data tells you whether today's costs are normal or elevated relative to the recent past — a distinction that current data alone cannot provide.

Data Pipeline Architecture

LiquidView's data pipeline is designed around reliability and parallelism. Every five minutes, a collection scheduler fires jobs for each (exchange, token pair) combination in parallel. Each job independently fetches the order book from its target exchange, runs the simulation for all size tiers, writes the results to the time-series database, and reports its completion status. If a job fails — due to an exchange API outage, rate limit, or network error — it logs the failure and the corresponding data point is recorded as a failed collection (the collection_success flag is set to false in the stored record).

The time-series database (QuestDB) is optimized for high-frequency writes and time-range queries, which matches the write pattern (many small records written every five minutes) and the read pattern (time-range queries for trending, most-recent-record queries for current state). The API server sits in front of the database, translating incoming API requests into efficient database queries and formatting the results as JSON responses.

• Scheduler: Fires parallel collection jobs every 5 minutes. Manages job timeouts and failure detection.
• Collectors: One per exchange. Responsible for rate-limit-compliant order book fetching, retry logic, and result normalization.
• Simulation engine: Receives normalized order book data, runs the order walk simulation for all size tiers, returns computed cost records.
• Time-series database: QuestDB. Stores all cost records with nanosecond-precision timestamps. Handles high write throughput and fast time-range queries.
• API server: Translates REST API requests into database queries. Applies caching for frequently requested queries. Returns structured JSON responses.

Accuracy and Limitations: What the Data Can and Cannot Tell You

LiquidView's execution cost estimates are highly accurate for small to medium order sizes under normal market conditions. For orders up to approximately $50K on liquid pairs (BTC, ETH), the simulated cost closely matches realized cost because liquidity at the best levels is sufficient to fill the order without walking significantly into the book. The fee component is exact (fees are deterministic given the fee schedule and order size). The spread component is accurate to within the measurement latency of the order book snapshot.

Accuracy decreases for large orders during periods of low liquidity. For a $500K order during a high-volatility event when market makers have pulled their quotes, the actual order book at snapshot time may look very different from the order book 30 seconds later when you execute. The simulation will correctly reflect the snapshot-time cost, but actual execution cost may be significantly higher. This is the inherent limitation of any simulation approach: it models cost at a point in time, not during a live execution.

• Fee accuracy: Very high. Fees are deterministic and well-documented. LiquidView uses standard taker tier rates; if your account has a custom fee tier, your actual fee may differ.
• Spread accuracy: High under normal conditions. Spread can change rapidly during volatility events; the 5-minute snapshot frequency means spread estimates may lag reality during fast-moving markets.
• Price impact accuracy for small orders ($1K–$25K): High. These order sizes are typically well within the best level liquidity.
• Price impact accuracy for large orders ($100K+): Moderate. Estimate accuracy depends heavily on how stable order book depth is between the snapshot and execution times.
• Accuracy during market stress: Lower than normal conditions for all components. Treat LiquidView estimates during high-volatility periods as directional guidance rather than precise predictions.