[Note 04] ·
Notes from the desk
Oracle latency as infrastructure cost
Most infrastructure costs are explicit. Compute, network bandwidth, and exchange connectivity each appear on an invoice and are straightforward to reason about. Oracle latency is different: it is a cost that accrues on every decision that depends on an external price reference, without appearing on any bill.
In automated digital-asset systems, oracle data serves several functions simultaneously. It provides the reference price for settlement calculations, anchors strategy signals, marks positions against an external fair value, and feeds risk limits. The distribution of latency in how that data arrives is, in effect, a tax on all of those functions at once.
The two most common delivery architectures sit at opposite ends of a latency distribution. A relay service broadcasts an aggregated oracle output to multiple subscribers over shared infrastructure. The aggregation, routing, and contention introduced by that architecture add cumulative lag that in observed production data typically falls between 1.2 and 1.6 seconds from the oracle’s own observation timestamp — a median of approximately 1,380 milliseconds.
Direct feed access — a dedicated connection to the oracle’s native delivery infrastructure — removes the intermediate aggregation step. Because the connection is point-to-point, latency at the median drops to the low hundreds of milliseconds. The two distributions are shown in the histogram below.
The operational significance depends on the decision frequency and time-sensitivity of the use case. For end-of-day analytics or position reporting, a 1.3-second oracle lag is invisible. For any system operating within a sub-second decision window — hedging, rebalancing, or adjusting quotes on a fast-moving instrument — the relay’s tail distribution is a binding constraint on what the system can achieve.
There is a less obvious cost that compounds across the tail. A relay distribution with a 1.5-second 90th percentile means that a meaningful fraction of oracle updates arrive late enough to create a genuine choice: act on data that is now stale, or wait and introduce timing uncertainty. In a high-frequency context, both branches carry a cost. The stale-data path risks acting into adverse selection; the wait path sacrifices the opportunity that triggered the decision. Direct feed access does not remove this tradeoff, but it shifts the tail significantly leftward and narrows the distribution width, reducing the frequency with which the choice arises.
The framing that follows from this is straightforward. Oracle data access belongs in the same infrastructure budget conversation as colocation, network route selection, and exchange connectivity. The latency budget it consumes is drawn from the same finite pool. Treating oracle access as a data subscription — a recurring line item separate from the execution stack — is a category error that tends to be invisible right up until it isn’t.