# The Factory Census: measuring venues by the pairs they win, not the logos they add

> Canonical: https://blazephoenix.xyz/learn/the-factory-census
> License: CC BY 4.0 (attribution + link) · © 2026 BlazePhoenix
> Updated: 2026-08-26



Aggregators advertise venue coverage the way cereal boxes advertise vitamins: a logo wall, a count, an implication of depth. A venue integration, though, is a claim — and claims, in this project, get instruments. The factory census asks three questions of every registered venue on every chain, over a fixed corpus of real trading pairs: is it registered? does it hold a pool for the pair? and did it win the pair — supply a leg of the route the engine actually chose?

The three columns share one denominator (hop-pairs), and the census carries an explicit unresolved bucket for any leg it cannot attribute — a bucket that measured zero on all four chains. Every leg of every winning route is attributed to a named factory. Nothing is unexplained, which is what separates a measurement from a dashboard.

## The result that rewrote the V4 story

On Arbitrum, over 88 censused hop-pairs, the Uniswap V4 family — native and wrapped anchors together — wins 48: more pairs than any other registered venue, the canonical Uniswap V3 factory included, at 33. On Optimism, the census records what is, to our knowledge, the first V4-routed aggregation on the chain. These are attribution numbers from executed routes, not liquidity-dashboard estimates.

The V4 result confirms, from the outside, an ordering decision made inside the scan: a pair against the chain's native asset has two possible keys in V4 — one native, one wrapped — and the native key is the deep one, measured at 3.76 times deeper than its wrapped sibling on Base and 292 times on Robinhood Chain. The scan probes the native key first, so its bounded probe budget is spent on the side of the pair that actually holds the liquidity. The census is what that ordering is worth when it meets real liquidity: the family out-wins every incumbent on Arbitrum.

## Measured with the production wiring

The census harness does not approximate the deployment; it inherits it. The harness deploys through the same deployment path the chains receive, behind an equality gate that fails the suite if the two ever drift — so the wiring being measured is, verifiably, the wiring in production. A green suite that exercises different wiring than the chain runs proves nothing about the chain; the census closes that door structurally.

Alongside it, every venue sweep now carries an anti-vacuity gate: a pair reported as having depth must also quote non-zero. A venue family that silently stops quoting turns the suite red instead of quietly disappearing from routes — absence of a measurement is not a measurement, and the gate makes that principle mechanical.

## A pruning instrument, not a trophy cabinet

The census cuts both ways, deliberately. A factory that registers, holds pools, and wins nothing across hundreds of measured pairs is a retirement candidate — priced by attribution, not by reputation or logo value. That is the same discipline the registry applies to individual pools (vitality decays, the weak are evicted by the measurably healthier), applied one level up, to venues.

And it has already been applied at full severity: two working venue families were excised from the codebase outright in a hardening round, because supporting them required trust assumptions — a token approval, a caller-attested depth figure, an exception in the pair-authenticity proof — that the rest of the engine refuses. Coverage that can only be bought with an unmeasured trust assumption is not coverage. Subtraction is a first-class engineering move here, and the census is the instrument that keeps the roster honest in both directions.

**Verify it yourself:** git clone https://github.com/blazephoenixxyz-crypto/Blaze-Phoenix-Dex && cd Blaze-Phoenix-Dex && forge test --match-path test/fork/TokenSweep.t.sol -vv  # the public sweep whose fixtures and anti-vacuity gate the census shares; needs an RPC key

Related: https://blazephoenix.xyz/learn/deterministic-v4-discovery · https://blazephoenix.xyz/learn/uniswap-v4-end-to-end · https://blazephoenix.xyz/learn/the-fidelity-matrix · https://blazephoenix.xyz/learn/metrological-design