When More Onchain Feeds Carry Less Information

More publishers can make an onchain price look better diversified without adding independent information. In a minimal benchmark, duplicated feeds become extra weight when every interface gets a vote.

Overview. Ten observable feeds, two upstream facts: under one-interface, one-vote counting, one fact gets nine seats.

A protocol starts with two independent upstream facts behind its reference price. Then eight more onchain feeds appear—more publishers, more report paths, more interfaces a dashboard can count.

Ten feeds look like diversification. In the benchmark, the eight new feeds carry exact copies of one original source error. The interface list got longer; the primitive information set did not.

If each observable feed gets one vote when the protocol forms its aggregate, a copy adds no new fact but does add representation. Holding everything else fixed, the only thing that changes is how many times each upstream fact gets counted in the reference price.

Throughout this article, “more informative” means lower source-side mean-squared error around the latent value $V$, holding the primitive information process fixed. A higher source-side error floor $\Phi$ means a noisier aggregate under that criterion—not a claim about mutual information, Fisher information, or a separately estimated posterior.

The previous benchmark asked whether more traders mean more information. This one asks the same question one layer upstream: whether more onchain feeds mean more independent facts.

Where duplicated information can enter an onchain price

An onchain reference price is rarely a single raw observation. It is usually the end of a short pipeline:

upstream markets or data → publishers or data providers → observable onchain feeds → an aggregation rule → a reference price the protocol actually reads.

Each arrow can look like diversification. A lending market, perpetual venue, or settlement contract may see several publishers, several feed contracts, or several reported prices. Those objects are architectural interfaces. They need not be independent upstream information. Several publishers can ultimately depend on overlapping spot venues, indexes, derived marks, or the same vendor snapshot. Two feed addresses can publish numbers that move together because they are reading the same underlying market, not because they discovered two facts.

So publisher count, feed count, and independent-information count are different economic objects. Architectural multiplicity asks how many interfaces exist—how many publishers, feeds, nodes, or report paths the protocol can point at. Informational multiplicity asks how many genuinely distinct upstream information families those interfaces represent. Counting interfaces answers an operations question. Counting independent facts answers an information question. Confusing the two is easy precisely because both show up as “more sources” in a dashboard.

An onchain system can decentralize who publishes a price faster than it diversifies where the information behind that price comes from. That is a conjectural architectural possibility, not an empirical claim about any named network. The point of stating it here is only to fix the objects: visible publisher growth need not imply a larger primitive information budget.

That is why source aggregation matters onchain: a reference price can feed collateral checks, liquidation logic, mark prices, funding, or settlement. If the aggregate is noisier about $V$ under the benchmark below, every downstream rule that reads that aggregate inherits the noisier input. This note stops one layer earlier—it asks only how the source network and weighting rule shape the reference price itself. Downstream protocol outcomes are not modeled here.

Source count was still too simple

The earlier model kept trader count and source count as different state variables: $N_T \neq K$. A larger crowd averaged out interpretation noise; a source-side floor remained.

$$ \mathrm{MSE}(N_T)=\text{source-side floor}+\frac{\sigma_\nu^2}{N_T}. $$

That floor still sits under this note. What the exchangeable-source benchmark still compressed was the source side itself—dependence into one shared parameter—so adding another source could never raise the source-side error floor through representation alone. Every source was treated as symmetric with every other source.

Drop that symmetry and one independent fact can appear through many more interfaces than another. Shared dependence and unbalanced representation are different failures. The first says feeds overlap. The second says one information family can dominate the vote when each interface is counted equally. A protocol that only tracks average pairwise correlation can miss the second failure entirely. That is the experiment here.

Graph → dependence

Map the plumbing onto three layers: independent facts, observable feeds, and one aggregate the protocol can read. Let $K$ be the observable feed count and $K_Z$ the number of independent primitive information components—I will call these “facts” in the prose. In protocol language, $K$ is closer to “how many interfaces are attached,” and $K_Z$ is closer to “how many distinct upstream information families those interfaces actually carry.”

$$ s=V\mathbf{1}+Az+\varepsilon. $$

$A$ records which primitive facts appear in which observable feeds. Multiple feeds can carry the same fact. The aggregate sees feed values, not a label that says “copy.”

$$ P=w^\top s,\qquad \Sigma=\operatorname{Cov}(s-V\mathbf{1}),\qquad \Phi=\operatorname{Var}(P-V)=w^\top\Sigma w. $$

$P$ is a benchmark aggregate formed from observable feeds ($\mathbf{1}^\top w=1$), not a calibrated production-oracle price. $\Sigma$ describes dependence; $w$ describes influence. Unbalanced dependence combined with interface weighting is what turns copies into influence.

Three architectures with the same $K=10$:

1. Independent: ten feeds, ten facts—interface count and information count coincide.
2. Common: ten feeds, one shared fact—the old exchangeable-dependence world, where many interfaces mostly move together.
3. Copies: ten feeds, two facts, one repeated many times—the case where architectural multiplicity and informational multiplicity diverge most sharply.

Fig. 1. Where each observable feed gets its information. Same $K=10$, different $K_Z$. Circles are facts $z$, squares are feeds $s$, and $P$ is the equal-weight aggregate. The figure does not map any named oracle onto one of these graphs.

The graph tells us where feeds come from. $\Sigma$ translates that structure into dependence. The weighting rule then determines how that dependence enters the aggregate.

Fig. 2. Feed-error covariance $\Sigma$ under the same three architectures. Independent: diagonal only. Common: exchangeable shared dependence. Copies: a $9\times9$ covariance block for one information family and one feed independent of that block. Heatmaps show dependence only; the copy-vote result needs dependence plus equal feed weighting.

Copies become votes

Smallest benchmark: two independent unit-quality source errors under the simplest interface-counting rule a protocol might use—every attached feed receives equal weight. With no duplication, $K=K_Z=2$ and $\Phi=0.5$.

Duplicate the first source $M$ times. Then $K=2+M$ while $K_Z$ stays 2. Equal weights are $w=\frac{1}{K}\mathbf{1}$—each of the $K$ observable feeds receives weight $1/K$. Under that rule:

$$ \Phi_{\mathrm{eq}}(M)=\frac{(M+1)^2+1}{(M+2)^2}. $$

At $M=8$, ten feeds are visible, but nine come from one fact and one from the other. The aggregate is much closer to a nine-to-one mixture than to an equal split between two facts. Nothing in the primitive layer got noisier. Influence did.

Closed form and simulation both give

$$ \Phi_{\mathrm{eq}}:\ 0.500 \rightarrow 0.556 \rightarrow 0.625 \rightarrow 0.722 \rightarrow 0.820 $$

on the frozen grid $M\in{0,1,2,4,8}$. Under this benchmark, that rise means a noisier aggregate about $V$—less informative under the source-side MSE criterion above.

Fig. 3. What happens when the weighting rule gives repeated interfaces repeated influence. Source-side error floor $\Phi=w^\top\Sigma w$ against duplicate count $M$, with $K_Z=2$ fixed. Equal feed weighting rises from 0.50 to 0.82; duplication-aware family weighting stays at 0.50. Same $\Sigma$ family as Fig. 2's Copies panel.

The flat line is not a slogan. For exact copies, define the duplication-aware benchmark at the information-family level. If there are $K_Z$ unique primitive families, assign each family total aggregate weight

$$ g_j=\frac{1}{K_Z}. $$

If family $j$ contains $m_j$ exact observable copies and its family weight is split equally among them, each copy receives

$$ w_i^\star=\frac{1}{K_Z m_j}. $$

In the article’s $9+1$ case, family A receives total weight $1/2$ and each of its nine feeds gets $1/18$; family B receives total weight $1/2$. Then $\Phi^\star=0.5$ for every $M$. Equal interface weights and family-neutralized weights face the same $\Sigma$; only $w$ changes. This is a benchmark that neutralizes exact duplication, not a recommendation for production oracle design.

A copy adds no information. Under interface-counting, it still adds a vote. Two analysts, A and B, each with one independent signal; eight outlets repeat only A—a one-outlet, one-vote average behaves as if A became more informative under this benchmark. It did not. A got more seats.

The exchangeable-source benchmark could already represent shared information. It could not represent one information family receiving more seats simply because it appeared through more feeds—the failure mode that matters when a protocol attaches many interfaces that still recycle a small upstream budget.

What this means onchain

For an onchain reader, the key distinction is between architectural multiplicity and informational multiplicity: how many publishers, feeds, or interfaces exist versus how many distinct upstream information families they actually represent. A protocol can add feeds without adding independent information—and if every interface receives equal weight, the most repeated information family can gain disproportionate influence over the reference price.

That matters because reference prices often sit upstream of collateral checks, liquidations, mark prices, funding, or settlement. This simulation does not model those downstream effects; it isolates the source-aggregation layer that feeds them.

It also does not claim that any production oracle has the exact-copy structure used here. The empirical question is simpler: before treating “more feeds” as “more information,” measure the shared upstream inputs, how they cluster into information families, and how much aggregate weight those families ultimately receive.

Closing

For an onchain price system, “how many sources?” is too coarse a question. What matters is how many independent information families those sources represent—and how much weight each family ultimately gets.

The market did not learn more. It reweighted what it already knew.

Appendix

• Model. Exact-copy grid $M\in{0,1,2,4,8}$ under equal feed weights; source-side error floor $\Phi=\operatorname{Var}(P-V)=w^\top\Sigma w$. Duplication-aware path uses family weights $g_j=1/K_Z$ with equal split inside each exact-copy class, so $\Phi^\star$ stays flat while $\Phi_{\mathrm{eq}}$ rises.
• Implementation. Rust crate market-information-capacity.
• Scope. Internal mechanism only—no named oracle or venue estimated here.
• Related: When More Traders Stop Adding Much Information (direct predecessor) · When Three AMM Pools Start Moving Like One (empirical companion on venue count vs integration).