Why quotes diverge across different exchanges and how this breaks trading
Quote divergence is not a rarity or a failure of an individual exchange, but a normal state of the market. A pool on one venue updates its reserves after a large trade, while on another it still holds the previous values, and the router is already building a price from them.
If a dex price comparison system reads reserves with a delay of tens of seconds, it shows a price that no longer exists on the market: an arbitrageur takes the difference, and your swap executes at the worst rate.
The root of the problem lies in how pool state updates are structured. Reserves change with every swap, and time passes between the moment of the trade and the moment the new price reaches your interface.
The deeper the pool liquidity and the more frequent the trades, the faster the data becomes stale: a quote taken a minute ago is already outdated for an active pair. Stale reserves are dangerous because they look plausible — the numbers are valid, just from the past.
The second layer is slippage, which is not visible in the moment. The rate an aggregator shows is the price before the trade. As soon as the order enters the pool, it shifts the reserves itself, and the actual execution price turns out worse.
On thin pools, the gap between the interface and execution reaches several percent, and it is precisely on this that both traders and services that build their logic on such data lose money.
The third source of errors is routing. When splitting a large order across several pools, the aggregator must account for the fact that each subsequent step changes the reserves of the previous one.
Without recalculating the state after each step, the estimated price diverges from the real one, and quote divergence grows along with the order size.
The bottom line: as long as pool data arrives with a delay and slippage is not accounted for in the calculation, any price comparison remains approximate.
We break down how this is closed — from indexing pool state in real time to calculating the execution price with an adjustment for depth.
What off-chain indexing and a realtime API provide
Off-chain indexing moves the main work out of the blockchain and into its own database: the indexer listens to pool events, recalculates reserves and prices after every trade, and stores the result in a storage from which the API serves quotes.
The smart contract remains the source of truth, but a client request no longer waits for block confirmation — the response comes from prepared data in tens of milliseconds instead of seconds.
Response speed is made up of two things: a hot cache for popular pairs and the absence of synchronous network calls on every request.
When a user opens a price comparison, the system already holds up-to-date values for all tracked markets, so the output does not depend on how loaded the node is at that moment.
Pool coverage grows not "by eye" but through normalization: the indexer brings different market formats to a unified model of a pair, token, and fee, so the comparison includes both large exchanges and small pools that usually fall out of the output.
Load resilience is ensured by separating reads and writes: request spikes hit the cache and replicas rather than the indexer, and quote updates continue even with a multiple increase in traffic.
The practical effect is that price comparison remains accurate and fast at the moments when the market is moving most actively, and expanding the list of pools does not require rewriting the client side. Let's break down how this works in a specific implementation.
Ways to get quotes: direct reading, indexer, hybrid
The three approaches differ not in "speed" in a general sense, but in where the delay occurs and who pays for each request.
Direct reading of contracts gives the freshest data — you query the pool at the moment of the user's request and get the state at the current block.
The price for this is network latency on every call and a growth in the number of requests to the node proportional to traffic: with hundreds of simultaneous comparisons, a public node starts returning errors, and a private one requires headroom in throughput.
An indexer shifts the load to its own side: a background task listens to pool events, recalculates reserves, and stores the result in its own database.
A user request is served from it in a matter of milliseconds, and the cost of accessing the network does not depend on the number of visitors.
The limitation is data latency: time passes between an event on the blockchain and the update of the record, and on chain reorganizations a rollback of already recorded states is needed, otherwise the output will retain prices from a vanished branch.
The hybrid covers both edges: the indexer holds the main flow and delivers a fast response, while direct reading is enabled selectively — for large trades, rare pairs, and moments when the discrepancy between the calculated and actual price exceeds a threshold. This way latency stays low on mass requests, and accuracy stays high where an error costs more.
| Approach | When it fits | Limitations |
|---|---|---|
| Direct reading of contracts | A small number of pairs, one-off checks, need the price at the current block | Latency on every call, request cost grows with traffic, the node becomes a bottleneck |
| Indexer | Many pairs and pools, high volume of comparisons, need a fast response | Data latency on updates, rollback on reorganizations, own infrastructure and monitoring |
| Hybrid | A production aggregator with mass traffic and scenarios sensitive to accuracy | Harder to maintain: two collection branches, reconciliation rules, and discrepancy thresholds |
The choice is dictated by the load profile: while requests number in the dozens per minute, direct reading is simpler and more honest in terms of freshness.
As soon as price comparison becomes a mass scenario, the indexer stops being an optimization and becomes a condition for operability, and the hybrid becomes a way not to pay with accuracy for speed.
How we build the system: from pool audit to handover
The work proceeds in stages, and at each one the client sees an intermediate result rather than a "big release at the end." The order is arranged so that errors in the data model and routing logic surface before they turn into quote discrepancies in production.
- Audit of pools and sources. We compile a list of exchanges and pools that actually provide liquidity for the required pairs: we look at depth, fees, the availability and quality of public interfaces, and the stability of data delivery. We filter out dummy pools where there is a price but no volume — otherwise the aggregator will show a beautiful but unexecutable rate.
- Schema design. We determine how we store pools, tokens, pairs, and reserve snapshots, how we link them to each other, and how we calculate price taking into account fees and slippage. Here we also fix the API response format so that the frontend and external consumers receive the same structure.
- Setting up indexing. We set up data collection from sources: event subscriptions and periodic polling for those that do not provide a stream. We configure route recalculation when reserves change and deduplication rules so that the same pair is not pulled from multiple sources twice.
- Testing on historical data. We run the assembled logic over past periods: we compare calculated prices with what was actually in the pools, and we catch discrepancies during sharp market movements and on rare pairs. This filters out errors that on a live stream are only noticeable at moments of volatility.
- Load and resilience. We check how the system behaves as the number of pairs and requests grows, what happens when an individual source becomes unavailable, and how quickly indexing recovers after a failure.
- Handover of documentation. We provide a description of the data schema, instructions for connecting new pools and configuring thresholds, as well as a breakdown of how to read indexing metrics.
- Post-launch support. We help with the first updates: adding exchanges, changing calculation logic, and responding to format changes at sources.
This order produces a predictable result: by the time of handover, the client's team has a working DEX price comparison system and a clear instruction on how to develop it on their own.
What the client retains after implementation
After project handover, you are left not with a "black box" but with a working system and a complete set of engineering documentation. A price indexer is a pipeline that lives and changes: new pools appear, exchanges change contracts, and API load grows.
That is why we hand over everything needed for independent operation and development without our team.
- Indexer configurations — files describing sources, pool addresses, polling intervals, and price normalization rules. You change the list of exchanges or add a new pool by editing the config, without rebuilding the core.
- Data flow diagrams — from receiving an event from the network to writing to storage and serving via API. You can see where deduplication happens, where the weighted average price is calculated, and where the failure points are.
- Access policies — separation of read and write permissions, keys for external API consumers, and per-client rate limits.
- Update procedures — how to roll out a new version of the indexer, how to change the storage schema without downtime, and how to roll back to a previous release if something goes wrong.
- API documentation — descriptions of endpoints, response formats, error codes, and request examples. Enough for your developers to connect the aggregator to their product without back-and-forth with us.
- Monitoring and alerts — configured checks for source availability, indexing latency, and price discrepancies. You learn about a problem before your users do.
- Deployment guide — a step-by-step setup of the system from scratch on your infrastructure, including dependencies and environment variables.
We walk through each artifact with your team during handover: we show what is where, how to change it, and what to check after changes. Describe your task — we will come back with an estimate and a handover plan.
Case study: how a price feed aggregator stopped lagging behind the market
The client came with a working price feed aggregator: the frontend displayed prices, but traders complained that by the time they clicked, the price had already moved.
Measurements confirmed the worst — data lagged behind the market by an average of 8 seconds, and because only "popular" pools were polled, about 30% of liquidity bypassed indexing. In a volatile market, this meant a systematic loss on execution and a loss of trust in the service.
What we changed
We broke down the path of a quote from an on-chain event to the API response and rewrote it into three layers. The indexer subscribed to pool events via streaming subscriptions instead of periodic polling — new reserves enter processing the moment they change, not on a schedule.
Pool state is kept in memory with a change log: price recalculation runs on current reserves, not on the last snapshot from the database.
Coverage was expanded to all pools of the target networks, including low-liquidity ones: their share in routes was exactly what produced the slippage that the old index did not see.
The realtime API serves quotes over a persistent connection with a subscription to specific pairs — the client receives an update immediately, without repeated requests.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Quote latency | ~8 s | ~1.2 s |
| Pool coverage | ~70% | full |
| Price update | on a schedule | on an on-chain event |
Latency was cut by dropping polling and unnecessary writes to the database on the hot path. Full coverage eliminated the class of errors where a route was built on an incomplete picture of liquidity.
Resilience was addressed separately: when a connection drops, the indexer catches up on missed events from the log, so divergence from the network does not accumulate.
The project was led by our engineers on a stack of Chainlink for oracle streams and proprietary indexing services. If your price feed aggregator is hitting latency limits or incomplete pool coverage — describe your task, and we will come back with an estimate and a plan.
How does off-chain indexing differ from on-chain queries?
An on-chain query is a contract call that reads pool state directly at the moment of access.
For a DEX price comparison system, this means every quote update costs gas, and the result is limited by what a single call can return: to gather a price across dozens of pools and routes, you either have to split the requests or accept an incomplete picture.
Speed here is limited not by our infrastructure, but by block time and the limits on computation volume within a single transaction.
Off-chain indexing flips the scheme: an indexer listens to pool events, collects reserves and trades into its own database, and recalculates prices on its side. The contract remains the source of truth, but we read it once — during indexing, not on every user request.
This yields two consequences: gas cost stops depending on the number of API calls, and response speed is determined by our database rather than block time.
In terms of gas cost, the difference is fundamental. The on-chain approach pays for every request and scales poorly: growth in the number of pairs and routes increases expenditure linearly.
Off-chain pays a fixed cost for indexing — a single event stream serves any number of clients, and the cost does not grow with the load on comparison.
In terms of speed, on-chain is limited by block frequency and confirmation latency — a fresh quote arrives with a delay, and heavy computation across many pools simply does not fit into a single call.
Off-chain returns a result from a prepared index in milliseconds and updates it as events arrive, so the price comparison front end stays current under a high request rate.
Support complexity also diverges. On-chain logic lives in the contract: it cannot be fixed without a deployment, and an error in route calculation is costly.
An off-chain indexer is updated like an ordinary service, but it demands its own discipline — handling chain reorganizations, re-syncing after a failure, and reconciling its own state with the contract so the index does not drift from reality.
Common technical concerns when choosing a contractor
Before discussing timelines and scope of work, clients check three things: whether the system will survive a node or network failure, whether it can handle non-standard pools, and what actually happens in the first weeks after launch. Below are answers to what most often comes up on technical calls.
How does the system behave if a node or the network is unavailable?
The indexer is not tied to a single source: data streams run in parallel from multiple nodes and backup providers, and when one degrades, traffic is redistributed without stopping output.
Pool state and exchange rate are stored in local storage, so the API continues to serve the last confirmed quotes while the network recovers. After connectivity returns, the indexer catches up on missed blocks and verifies checksums — no discrepancies remain in the history.
Do you support non-standard networks and pools?
Standard AMM pools are connected using a proven template, while non-standard ones — pools with non-linear formulas, multiple tokens in a pair, or custom fee logic — are handled separately and the pricing rules are described for the specific contract.
The list of networks expands without rewriting the core: an adapter for the new network is added, and the rest of the system is untouched. If a pool changes its mechanics, the adapter is updated in a targeted way.
How long does implementation take and how is monitoring set up?
The first working loop with indexing and API is brought up in iterations: first the core and base networks, then non-standard pools and expanded coverage. As work progresses, you see intermediate results, not just the final outcome.
Monitoring covers indexing latency, quote discrepancies between sources, and API availability — when thresholds are exceeded, an alert is triggered rather than a user complaint. Metrics and logs remain with you, so the system's state is transparent even after handover.
Let's discuss your quote collection task
To make the estimate substantive rather than a "market average", we need three things from you: the list of exchanges and networks you collect quotes from, requirements for update frequency and history depth, as well as the expected load — how many clients and requests per second your product handles.
With this set, we understand what volume of off-chain indexing will be required and where the bottlenecks are: in polling sources, in normalizing pairs, or in serving through the realtime API.
Then we work like this: our engineers analyze the sources for rate limits and response stability, verify your requirements against the actual behavior of the exchanges, and only after that finalize the architecture and work plan.
If for some data pairs there is objectively not enough data, we will say so directly — instead of promises to "collect everything", you will get an honest picture of coverage.
Here is what you will get from the discussion:
- an analysis of your sources: which exchanges and networks deliver quotes reliably, and where workaround polling schemes are needed;
- a project estimate broken down by stages — from collection to delivery in the API;
- a work plan with the launch order: first the indexing core, then the realtime layer and history;
- a storage and pair normalization scheme so that price comparison is correct across venues;
- infrastructure requirements for your expected load;
- risks for each source and options for mitigating them;
- a consultation with an engineer who has already built similar aggregators — on your specific questions.
Describe the task: which exchanges and networks, what update frequency is needed, how the product will use the data. We will come back with a project estimate and work plan — with stages, timelines, and what will be required from your side.