The Accuracy-Latency Trade-off in Multi-Source Price Feeds
Why This Trade-off Matters
Every DeFi protocol that liquidates a position, settles a perpetual contract, or prices a swap depends on an oracle — a system that pulls price data from multiple independent sources and produces a single, trustworthy number. The catch is that no two sources agree on both speed and quality at once. A centralized exchange tick feed arrives in tens of milliseconds but carries more microstructure noise. A TWAP feed from a decentralized exchange is smoother and harder to manipulate but arrives late. An institutional NBBO feed is extremely accurate but slow to publish.
An oracle aggregator therefore faces a genuine optimization problem: wait for more sources and get a more accurate price, or aggregate early and accept more error, but reduce the window during which the reported price is stale relative to the real market. This article builds a concrete, simulate-able model of that trade-off and finds the optimal quorum size — the number of sources the aggregator should wait for — as a function of how expensive latency is considered to be.
Modeling the Problem
Assume the true mid-price follows a simple diffusion process over the short aggregation window:
$$
dP_t = \sigma_P , dW_t
$$
Each source $i$ reports an observation $t_i$ ms after the aggregation round begins, with its own arrival-time distribution and its own measurement noise:
$$
p_i = P(t_i) + \epsilon_i, \qquad \epsilon_i \sim \mathcal{N}(0,\sigma_i^2)
$$
If the aggregator finalizes its answer at time $T$, then any source that reported at $t_i < T$ is “stale” — the true price has since drifted, and that drift itself behaves like noise:
$$
\mathrm{Var}\big[P(T)-P(t_i)\mid t_i\big] = \sigma_P^2,(T-t_i)
$$
So the effective variance of source $i$’s contribution, as seen from the aggregation deadline $T$, is
$$
\tilde\sigma_i^2(T) = \sigma_i^2 + \sigma_P^2,(T-t_i)
$$
Given a quorum of $k$ sources, the minimum-variance unbiased combination (the classical BLUE estimator) weights each source by the inverse of its effective variance:
$$
w_i = \frac{1/\tilde\sigma_i^2(T)}{\sum_{j=1}^{k} 1/\tilde\sigma_j^2(T)}, \qquad
\mathrm{MSE}(k) = \left(\sum_{i=1}^{k} \frac{1}{\tilde\sigma_i^2(T)}\right)^{-1}
$$
The aggregator’s decision variable is the quorum size $k$: waiting for the $k$-th source to arrive fixes the effective deadline $T_k$ as the $k$-th order statistic of the arrival times. The overall objective balances expected squared error against the cost of latency, priced by a coefficient $\lambda$:
$$
\mathcal{L}(k,\lambda) = \mathbb{E}[\mathrm{MSE}(k)] + \lambda,\mathbb{E}[T_k], \qquad
k^*(\lambda) = \arg\min_{k} \mathcal{L}(k,\lambda)
$$
$\lambda$ represents how expensive one additional millisecond of latency is, expressed in the same variance units as the pricing error — a higher $\lambda$ corresponds to applications like liquidation engines or MEV-sensitive settlement, where staleness is costly; a lower $\lambda$ suits applications like slow-moving collateral valuation.
Simulation Design
Six representative sources are modeled, each with a Gamma-distributed arrival time (shape 2) and a fixed measurement noise level:
| Source | Mean latency | Noise std |
|---|---|---|
| CEX Fast-Tick A | 40 ms | $0.50 |
| CEX Fast-Tick B | 60 ms | $0.80 |
| DEX TWAP (5-block) | 90 ms | $1.20 |
| DEX TWAP (30-block) | 130 ms | $1.80 |
| Institutional NBBO | 180 ms | $0.30 |
| Aggregator Node | 260 ms | $2.50 |
For each of 20,000 Monte Carlo trials, arrival times are drawn independently per source, sorted, and the closed-form BLUE variance formula above is applied directly to the first $k$ arrivals — no explicit noise sampling is needed, because the expected MSE has an exact analytical expression given the arrival times. This keeps the whole simulation vectorized and avoids the far more expensive approach of drawing noise realizations and averaging squared errors numerically.
Source Code
1 | import numpy as np |
Code Walkthrough
Source generation. Each source’s arrival time is drawn from a Gamma(shape=2, scale=mean/2) distribution, which produces a realistic right-skewed latency profile — most reports arrive close to the mean, but occasional stragglers arrive much later, just like real network and block-inclusion delays.
Sorting once, reusing everywhere. np.argsort on the arrival-time matrix gives, for every trial, the order in which sources reported. np.take_along_axis and fancy indexing then reorder both the arrival times and the corresponding noise variances into that same order. This means the first $k$ columns of sorted_t and sorted_sigma2 always represent “the $k$ fastest sources to report in this trial” — exactly what an aggregator with quorum $k$ would have used.
Why no noise sampling is needed. Rather than drawing $\epsilon_i$ explicitly and averaging squared errors over many draws (which would need either a second random dimension or far more trials to converge), the code uses the closed-form BLUE variance formula $\mathrm{MSE}(k) = \left(\sum 1/\tilde\sigma_i^2\right)^{-1}$ directly. Since this expression only depends on the arrival times, a single Monte Carlo dimension over arrival times is sufficient. This is the “fast” version of the simulation — it is exact in expectation and avoids an extra order of magnitude of computation.
Linear separability of the loss. Because $\mathbb{E}[\mathrm{MSE}(k) + \lambda T_k] = \mathbb{E}[\mathrm{MSE}(k)] + \lambda,\mathbb{E}[T_k]$, the code only needs to compute mean_mse and mean_T once per quorum size — the entire sweep over 40 values of $\lambda$ is then a single vectorized outer-product-style computation (loss_grid), with no additional simulation required.
Reading the Results
Source Mean latency (ms) Noise std ($) CEX Fast-Tick A 40.0 0.50 CEX Fast-Tick B 60.0 0.80 DEX TWAP (5-block) 90.0 1.20 DEX TWAP (30-block) 130.0 1.80 Institutional NBBO 180.0 0.30 Aggregator Node 260.0 2.50 k E[latency] (ms) E[MSE] ($^2) 1 24.36 0.8568 2 45.84 0.2654 3 73.47 0.1667 4 113.06 0.1261 5 178.40 0.0951 6 323.92 0.0808
Figure 1 — the Pareto frontier. Each point on this curve is a quorum size $k=1,\dots,6$. Moving right along the curve trades higher expected latency for lower expected squared error. The steepness between consecutive points shows where quorum increases are “cheap” (large error reduction for modest latency) versus where they become “expensive” (small error reduction, but a large latency jump, typically once the slow institutional and aggregator-node sources must be included).

Figure 2 — the 3D loss surface. This is the full picture of $\mathcal{L}(k,\lambda)$. Along the $k$-axis, the surface curves down initially (adding sources reduces variance) then curves back up (added sources contribute mostly latency once diminishing accuracy returns kick in). Along the $\lambda$-axis, the entire surface tilts — as latency becomes more expensive (larger $\lambda$, right side of the plot), the valley of the surface shifts toward smaller $k$. The white markers trace the ridge of optimal quorum choices $k^*(\lambda)$ across that tilt, visually confirming that there is no single “best” quorum size — it depends entirely on how costly staleness is for the specific application consuming the price feed.

Figure 3 — the regime map. This collapses the ridge from Figure 2 into a direct decision rule: for a given latency cost $\lambda$, what quorum size should the aggregator configure? The step structure shows discrete regimes — at very low $\lambda$ (latency nearly free), the optimum sits near $k=6$, using every source for maximum accuracy. As $\lambda$ increases, the optimal quorum steps down, eventually settling near $k=1$–$2$ once latency dominates the objective, favoring only the fastest sources even at a real accuracy cost.

Practical Implications
This framework maps directly onto real oracle architecture decisions. Protocols serving latency-sensitive functions — perpetual futures mark prices, liquidation triggers — sit on the high-$\lambda$ end of the regime map and should favor small, fast quorums, accepting more noise per update but compensating with higher update frequency. Protocols serving slower functions — collateral factor recalculation, governance-parameter feeds — sit on the low-$\lambda$ end and should wait for larger quorums including slower, high-quality sources like TWAPs and institutional feeds.
The same structure also explains why many production oracle systems (Chainlink-style networks included) use tiered aggregation: a fast layer with a small quorum for time-critical consumers, and a slower, larger-quorum layer for consumers where accuracy dominates. The model above gives a quantitative way to choose the quorum size for each tier rather than setting it by intuition alone, and the closed-form BLUE approach means the entire optimization can be recomputed cheaply whenever source latency or noise characteristics change — for instance, after adding a new exchange feed or observing degraded reliability from an existing one.





























