# The capital anchor: converting a statistical defence into an economic one, and the price of doing it

> Canonical: https://blazephoenix.xyz/learn/capital-anchor-breakdown-point
> License: CC BY 4.0 (attribution + link) · © 2026 BlazePhoenix
> Updated: 2026-08-13

BlazePhoenix filters candidate venues with a believability band of deployed tolerance 4% (MEDIAN_FILTER_BPS = 400), but the design decision is the centre: the reference is the rate of the candidate holding the largest real output-token balance — the capital anchor — with the median only a fallback, because on a permissionless chain the attacker chooses the sample and can outnumber a median with cheap dust pools. Defeating the anchor costs out-capitalising the deepest venue; the limit is stated in the same breath — an argmax has a breakdown point of zero.

A pool contract can quote any price it likes; quoting is arithmetic over numbers it stores. Holding tokens is the expensive part. Every defence against manipulated routing is therefore an attempt to make the quantity that decides the route expensive to move — and the interesting question is not whether a filter is robust, but which resource an attacker has to spend to defeat it.

BlazePhoenix filters candidate venues with a believability band: a candidate whose rate sits outside a fixed tolerance of a reference rate is dropped before routing. The deployed tolerance is 5% — MEDIAN_FILTER_BPS = 500. The design decision is not the width. It is what sits at the centre.

## Two candidate centres, two different threat models

The obvious centre is the median of the candidate rates, and the median is a genuinely good choice for a specific reason that is worth separating from folklore. The median minimises the maximum profit an attacker can extract by misreporting, with an explicit bound; a mean scales linearly with the size of the manipulation. One manipulated pool moves a median discretely and boundedly; it moves an average as far as the attacker's capital reaches. That result justifies the median as an aggregator — and says nothing whatsoever about the width of a band drawn around it.

But the median's guarantee carries a hidden assumption, and on a permissionless chain the assumption is the whole game. Robust statistics defends against a minority of corrupted observations in a sample the attacker did not choose. Here the attacker chooses the sample. Deploying shallow pools is cheap, and a candidate set can be populated with them. Once a majority of the observations are the attacker's, the median is the attacker's number, and it was obtained at the cost of deployment gas rather than at the cost of capital.

The deployed reference is therefore the rate of the candidate holding the largest output-token balance — the capital anchor — with the median retained only as a fallback for the case where no balance information is available. The band is centred on the pool with the most capital at stake rather than on the pool that most other pools agree with.

> equation: base={rate of the deepest candidateif any balance is knownmedian of the candidate ratesotherwise — The reference the believability band is drawn around. The second line is a fallback, not a co-equal branch — and it inherits the median's assumptions in full.

## What the substitution actually buys

The substitution replaces the proposition "most of these pools agree" with the proposition "the pool with the most capital at stake agrees". Attacking the first costs the price of deploying enough contracts to outnumber the honest ones. Attacking the second costs out-capitalising the deepest venue in the pair — and an attacker who genuinely holds more of the output token than any honest venue is not a manipulator sitting beside the market. At that point they are the market, and the price they quote is a price they are prepared to be filled at.

That is the honest form of the claim, and the direction of the improvement is economic rather than statistical. A balance read from a token contract cannot be faked without actually holding the tokens; a quote can be returned by any contract that implements the interface. Anchoring the band on the first quantity and judging candidates by the second means the free signal is checked against the expensive one, rather than the other way round.

## The limit, stated as sharply as the benefit

Selecting the deepest candidate is an argmax, and an argmax has a breakdown point of zero. Breakdown point is the standard robustness measure: the smallest fraction of contaminated observations that can drive an estimator arbitrarily far from the truth. For the median it is one half. For a maximum it is one observation — the single largest one determines the output completely, and there is no minority of honest observations left to outvote it.

So the capital anchor is not a robustness result and should never be reported as one. An attacker who genuinely is the deepest pool controls the anchor entirely, and every candidate whose rate lies outside 4% of that attacker's rate is excluded from routing by the filter working exactly as designed. What the construction does is convert a statistical defence into an economic one: it raises the price of the attack and it removes the statistical guarantee at the same time. Those are two halves of the same sentence and publishing only the first would be marketing.

The two failure profiles are complementary rather than ordered, which is the useful thing to know when reasoning about a specific pair. A median fails to a cheap Sybil majority and resists a single deep adversary. An argmax resists a Sybil majority entirely — extra shallow pools change nothing, because they never win the maximum — and fails to a single sufficiently deep adversary. The design chooses the second profile because on a public chain the first attack is the one that costs almost nothing.

```
estimator      breakdown point    defeated by                   cost to the attacker
median              1/2            majority of the candidate set   deployment gas
argmax (depth)      0              being the deepest pool          out-capitalising the venue
```

## Three mechanical limits that travel with the anchor

A candidate set of size one is not filtered at all. A band drawn around a single observation carries no information, so the filter is skipped rather than applied vacuously. That is the correct behaviour and it is also a hole: a pair for which exactly one venue is known receives no believability filtering whatsoever, and the guarantee falls back entirely to the output floor and the user's own minimum.

A venue that reports no balance cannot be an anchor. Some venue designs — the singleton style among them — do not expose a per-pool balance of the output token at all. A candidate set drawn from those venues falls back to the plain median and inherits the median's assumptions along with it, including the Sybil exposure the anchor was introduced to remove. The stronger guarantee is therefore conditional on the venue family, not on the protocol.

And the width of the band is a product decision, not a derived quantity. Nothing in the argument above determines 4% rather than 2%. A wider band admits more candidates, which means more tolerance for legitimate price dispersion and more access to liquidity, and it also lets slightly worse candidates through. The protocol pairs the wider band with the higher output floor deliberately — the floor rate is clamped so it can never fall below 80% — and that pairing is a judgement we are accountable for rather than a theorem we are reporting.

## What the anchor does not defend

The band decides which candidates are priced. It does not decide which candidates are considered. Upstream of it sits a registry whose slots are ranked by accumulated standing and then truncated, and a venue that loses that ranking is not filtered — it is never scored at all. Manipulating the candidate set upstream of the anchor is a materially cheaper attack than manipulating the anchor itself, and it is covered separately in the article on learned state. The anchor is a defence against a lying quote, not a defence against a curated list.

Nor does it protect against the case where the attacker controls a genuine deep venue and simply prices it badly within the band. Four per cent of a large trade is a large number. What bounds that residue is not the filter but the output floor the router derives in-frame and the minimum the user supplies — and the honest boundary for the whole family of registry and routing attacks is the same one: principal is out of reach, the user's slippage tolerance is not.

## How to check the doctrine by hand

The anchoring idea is one a reader can apply without our contracts at all, and it is the recommended due-diligence procedure for any token on any venue. Take a token's top pools from any screener. Read each pool's live balance of the output token directly from the token contract with balanceOf. Compare what the contracts actually hold against the depth the screener advertises. The gap is the phantom, and it is visible to anybody with an RPC endpoint and no privileged access of any kind.

Doing that by hand also makes the breakdown point concrete: run the comparison and ask which single pool would set the anchor for your trade, and whether you would be comfortable with that pool defining what counts as a believable price. If the answer is no, the filter will not save you, and the number that will is the minimum you set.

**Verify it yourself:** read a pool's real holdings yourself: cast call <token> "balanceOf(address)(uint256)" <pool> --rpc-url https://mainnet.base.org — then compare against the depth a screener advertises, and identify which single pool would be the anchor for your pair

Related: https://blazephoenix.xyz/learn/phantom-liquidity · https://blazephoenix.xyz/learn/capital-anchored-split · https://blazephoenix.xyz/learn/learned-state-boundary
