The cost of latency in onchain trading

Latency costs show up as the gap between the chain state a product observed and the state in which its action executes. That gap grows with every millisecond the product spends reading, deciding, submitting, and waiting for confirmation.

For a long-horizon portfolio view, that gap may be an annoyance. For a market maker, a swap router, a liquidation engine, or a trader trying to cancel a stale order, it can consume a meaningful share of the strategy's edge. Low-latency RPC is core to successful trading experiences because it helps these products act on newer state.

A quote can go stale before a trade executes

A swap quote captures pool reserves, order-book liquidity, gas conditions, and market state when the application asks for it. Those inputs keep changing while the user confirms a transaction.

The basic path is simple:

1. An app reads chain and market state.
2. It calculates a quote or trading decision.
3. The user submits a transaction.
4. The network propagates, sequences, and executes it.
5. The app receives a receipt and refreshes its view.

Each delay makes the final action less current. A slow read uses older market data; a slow submission gives the market more time to move; and a slow confirmation leaves users looking at stale status.

0x prices trades across liquidity sources. Its team ties responsive, accurate data to quote quality because prices can move while requests are in flight, and it generates those quotes in less than a second.

Jupiter illustrates the timing gap: its direct-landing path targets 50–400 milliseconds, or zero to one Solana blocks, versus 400 milliseconds to 1.2 seconds, or one to three blocks, for standard RPC submission. Fewer blocks between quote and execution leave fewer opportunities for the state to change.

The four stages where latency adds up

Every trade moves through these stages. Delay in any one of them makes the final outcome less current or less certain.

These stages interact. An old market read stays old even when the write path is fast. During a volatile burst, the slowest requests matter more than the average. Failures also create their own risk: retries, stale screens, and missed actions.

Latency-sensitive products should evaluate p95 and p99 response time alongside success rate. Our public benchmark methodology measures warmed, method-level EVM reads and reports successful-response latency separately from failures. The underlying Node API covers the reads and writes a product uses to interact with a chain. It measures a specific provider path, while a trading team needs to test its own reads, writes, regions, and traffic shape.

How does latency become an economic cost in onchain trading?

Latency becomes an economic cost when it changes execution outcomes, and how it does that depends on the workload. Here are the patterns that recur in onchain trading systems.

Swaps: a stale quote becomes slippage or a revert

Price impact and slippage are often lumped together, but they describe different costs. Our DeFi infrastructure guide shows how these costs appear in production quote flows. Price impact is the predictable change a trade causes in a pool's price at a given size. Slippage is the additional gap between the quoted output and the output received at execution. It depends on latency, concurrent transactions, and block inclusion order.

That distinction matters in product design. Price impact is visible at quote time. Slippage grows while a transaction is pending. A minimum-output guard protects the user by converting too much price movement into a revert. Lower-fee transactions can wait longer while the price environment changes; a minimum output, maximum input, or deadline sets the worst execution a user will accept.

The user-facing outcome is a worse price, a missed trade, or a tighter execution path that reduces exposure to a changing market. Faster reads and submission reduce one part of that exposure window.

Market making and order management: a late cancel can become toxic flow

Market makers continuously refresh quotes as prices move. If the system learns about a move late or sends a cancel late, a resting order can be filled after it has become unprofitable. Traders placing an immediate order face the opposite risk: by the time it reaches the market, the available liquidity may be gone.

Liquidations and arbitrage: time is part of the opportunity

Liquidation engines and arbitrage systems compete to observe a state change and act before the opportunity closes. The relevant race can be a new oracle price, a changed health factor, a pool imbalance, or a cross-venue price move. Missing it may mean lost revenue. Repeated failed attempts can also burn fees and consume blockspace.

Chain design changes the shape of this race. On systems that sequence by first arrival, a lower-latency path can be directly relevant to ordering. On systems that use priority fees, fees and timing both matter. On systems with private order flow or bundles, visibility and atomic execution introduce further trade-offs. Infrastructure operates within those market rules. Its job is to avoid adding unnecessary delay before a strategy enters them.

Wallets and trading interfaces: delay becomes a trust problem

Latency affects more than fill price. A wallet or trading app may issue many calls before a user sees a useful screen: balances, allowances, route quotes, gas estimates, receipts, and transaction history. If those calls return slowly or intermittently fail, users see changing prices, delayed status, or an interface that appears frozen.

That is especially damaging during volatility. The same slow balance refresh that is merely inconvenient in a quiet market can delay a hedge, a cancellation decision, or a deposit confirmation when a user is trying to manage risk.

Why tail latency matters more than an average

Latency distributions have tails. When an endpoint slows under load, the product experiences the slow path during rising traffic, volatility, or chain contention.

That is why a provider review should answer four questions:

• Which methods sit on the critical path? Evaluate a latest-block read, eth_call, eth_getLogs, receipt lookup, and transaction broadcast separately; each has different behavior.
• From which regions do users and services connect? Geography changes the network path.
• How slow are the p95 and p99 successful calls? Those values reveal the requests an average hides.
• How often do requests fail or time out? A timeout is a reliability event that can trigger retries, stale UI, or missed action.

A benchmark should make those conditions explicit and measure the product path a buyer actually runs. Our benchmark methodology fixes the request origin, method, payload, timeout, success rules, and connection state for each method-level comparison to help builders make infrastructure decisions.

What low-latency RPC can and cannot solve

A faster RPC layer can return current state sooner, submit a signed transaction sooner, and keep a trading interface responsive. Fill quality still depends on market movement, liquidity, fees, route selection, transaction protection, and a chain's sequencing policy. A provider's read benchmark measures read performance; end-to-end swap performance, transaction inclusion, WebSocket behavior, and strategy PnL require separate tests.

This scope keeps infrastructure claims honest and helps teams choose measurements that match their workload. The goal is to remove avoidable delay from the paths where a product's economics are most sensitive to time.

We built our low-latency RPC work around that goal. Alchemy Edge Proxy removes fixed request-path overhead at ingress and cut APAC p99 from 150 milliseconds to 20 milliseconds in its migration measurement. Cortex routing selects a healthy node per request rather than treating proximity as the whole answer. Cortex also underpins the capacity and fleet operations that keep the request path responsive under load. Our low-latency infrastructure work spans the edge, routing, capacity, node operations, and measurement. Each layer is fine-tuned to bring you reliable low-latency service.

How to evaluate your own execution path

Start with the flow where delay creates the greatest user or economic cost.

1. Map the path from state read to user-visible outcome, including route calculation, signing, submission, inclusion, and status refresh.
2. Test the methods and payloads your product actually uses from the regions where your services and users run. Start with the RPC API and supported chains your product depends on. Run the same test during normal and high-volatility or high-traffic periods.
3. Record p50, p95, p99, success rate, timeout rate, and quote-to-outcome time. Keep read, submission, and inclusion latency separate.
4. Connect those measurements to outcomes: quote-to-fill drift, reverts, missed fills, cancel success, support contacts, and user abandonment.

This creates a cost model for your strategy, assets, and users—and shows where a faster path changes execution outcomes.

Frequently asked questions

How does RPC latency affect trading performance?

Latency widens the gap between the state a trading app observed and the state its transaction executes in. Slow reads make a quote stale before it is signed, slow submission gives the market more time to move, and slow confirmation leaves users acting on an outdated screen. The result is worse fills, missed trades, or reverts.

Does lower RPC latency guarantee a better trade fill?

Lower RPC latency reduces avoidable delay before and during submission. Fill quality also depends on market movement, liquidity, fees, private order flow, route selection, chain sequencing, and transaction protection.

Why is p95 more useful than average RPC latency for trading apps?

An average can conceal the slow requests that cluster during load or volatility. P95 shows that 95% of successful responses were at least this fast under the measured conditions. Read it with success rate, since failures and timeouts need their own reliability measurement.

How do I benchmark an RPC provider for a trading app?

Test the methods and payloads your product actually uses, from the regions where your users and services run. Use our benchmark methodology as a reproducible starting point. Record p50, p95, p99, success rate, and timeout rate, and keep read, submission, and inclusion latency separate. Replay the test during volatile, high-traffic windows as well as quiet-market conditions.

Is price impact the same as slippage?

No. Price impact is the predictable effect of trade size on the current pool. Slippage is the execution-time difference between the quoted output and what the user receives. Raydium's documentation gives a clear technical definition of each.

Should trading teams benchmark reads, writes, and full workflows separately?

Yes. A method-level read test can compare provider behavior on a specific request. A full trading-flow test is needed to understand quote freshness, decisioning, submission, inclusion, and confirmation together. Keep the conclusions separate.