# Memory and measurement: what learned state may change, and what it may never touch

> Canonical: https://blazephoenix.xyz/learn/learned-state-boundary
> License: CC BY 4.0 (attribution + link) · © 2026 BlazePhoenix
> Updated: 2026-08-13

The shipped rule is one sentence — remembered state may change where the system looks, never what it accepts — applied to two different stores: probe hints can only reorder discovery attempts (written in one place, read in five, all inside discovery), while venue standing, earned solely by executed swaps and halving roughly every seven hours by lazy decay, ranks and then truncates the candidate list — which reaches route selection by omission, and the stronger formulation of the quarantine does not survive that; the leak is documented, not hidden.

A protocol that remembers anything has an adaptive component, and an adaptive component needs a stated boundary: what remembered state is permitted to influence, and what it must never touch. The rule we shipped is one sentence — remembered state may change where the system looks; it must not change what it accepts — and the useful part of this article is the account of where our own version of that rule leaks, because it does.

There are two distinct pieces of remembered state in the protocol and conflating them would let a guarantee that holds for one be read as covering the other. They are described separately below, strongest boundary first, and the difference between the two boundaries is the whole content.

## Probe hints: the boundary that holds

The protocol remembers a small amount of state about singleton venues, whose pools cannot be enumerated the way an ordinary factory's can. We call these probe hints. What is worth publishing about them is not what they learn but what they are permitted to do: a hint can only cause the discovery layer to try a particular configuration first. It never enters pricing, never enters allocation, and never narrows the candidate set.

That claim is worth exactly as much as the tracing behind it, so: the value is written in one place and read in five, all of them inside discovery, and it appears in no other file. The verification is a trace of every read and write of the value across the entire source, which is a cheap and complete method for a quantity that appears this rarely, and a method a reviewer can repeat.

The worst case therefore has a shape rather than a magnitude. A wrong hint costs a couple of wasted probes. A deliberately poisoned one can, in the narrow case where a dust pool gets admitted, suppress the broader cold-start search for that pair — which starves the route of candidates rather than steering it to a bad one. Stated in one sentence: a probe hint cannot misprice a venue and cannot remove one from consideration; it can only change the order in which venues are tried.

## Venue standing: earned only by being routed through

The second piece is a reputation for every trading venue the protocol has used. It is maintained entirely on-chain and needs no oracle, no keeper, no token and no vote. A venue's standing rises when a swap actually executes through it; the counter is written in exactly one place, only by the router, and only on the success path — so standing cannot be bought, declared, or granted. It is a record of work the protocol itself performed.

Standing also decays with wall-clock time, halving roughly every seven hours, so a venue that stops being used falls to nothing in about nine days. The decay is applied lazily, when the value is next read, which is why maintaining it costs nobody anything and requires no periodic transaction. A protocol that needs a keeper to age its own state has bought a dependency; this one ages by arithmetic.

What standing is allowed to decide is where the guarantee starts and where it stops. It does not enter a quote, does not enter the floor, does not weight the split between legs, and does not move a token — every one of those is computed from measurements taken during the transaction itself, and each read of the value was traced to confirm it. What it does decide is the candidate set: which venues occupy the limited registry slots for a pair, and the ranking used to select the top candidates before pricing begins.

## The leak: truncation reaches route selection by omission

That selection truncates, and truncation is where the stronger formulation dies. A venue with low standing is not priced badly; it is not priced at all. The attractive claim — that remembered state affects only how much work is done, never which route is taken — does not survive, because the option that was never scored cannot win. Memory reaches route selection by omission rather than by distortion.

The quarantine is nonetheless real and the distinction is the useful part: nothing a user receives is computed from remembered state, so an adversary who corrupts standing changes which venues are considered without being able to alter what any of them pays. Standing cannot misprice a venue. It can hide one. Those two sentences are the honest boundary, and the second is the one that gets left out of comparable descriptions elsewhere.

This is also the general shape of the failure, worth carrying to any system with a learned component. A boundary drawn around "search" leaks unless the guarantee is stated over the full set of options rather than over the surviving ones. Our boundary is enforced by construction and by convention, not by a specification a machine checks, and the next such boundary is likely to leak in a way we have not anticipated either.

```
probe hints   ->  ordering of discovery attempts only         (cannot hide a venue)
standing      ->  registry occupancy + ranking + truncation   (CAN hide a venue)
              ->  quote, floor, split weights, transfers      (never)

the guarantee holds over the SURVIVING candidate set.
it does not hold over the FULL set of venues that exist.
```

## Where the ranking is weak, stated in full

The quarantine holds. The ranking inside it does not hold as well, and this is the most substantial open weakness we know of in the protocol, so it is stated with its mechanism rather than as a caveat.

A venue's address is never authenticated. When a swap executes, the venue address credited with standing is taken from the route the caller supplied and passed into the registry untouched, with no check against a factory, a registry entry or a derived address. The pair it is credited under is likewise taken from the caller's own description of the hop, and the depth recorded for it is measured by calling the caller-supplied address itself. A contract that merely behaves like a pool can therefore introduce itself, choose which pair it competes in, and report its own depth.

The ranking then makes eviction hard to reverse. Standing saturates at a large ceiling while the depth term is capped at a much smaller one, and a newcomer is scored with the minimum standing — so a newcomer's best possible score is the depth cap alone, and any incumbent above roughly four fifths of that ceiling can no longer be displaced by any newcomer, however deep. Standing is bought with swaps, and swapping against a pool you own costs only gas, since you are the counterparty to your own fee and your own slippage.

And the same activity suppresses the search for alternatives. A registry with a few recently-stamped venues counts as fresh, and a fresh registry skips the discovery sweep entirely. Manufacturing standing therefore also reduces the chance that genuine venues are ever looked for — the same silence, exploited twice.

## Why a count is a weak observable

Standing is a count of events, and a count is a sum, so its blind spot is exactly the blind spot of a sum: every rewriting of the multiset of swaps with the same cardinality is invisible. Who swapped, how much, against whom, and whether the counterparty was the pool's own operator are all outside the observable. Depth enters only through coarse bucketing, so an order of magnitude of real depth is a single bit and everything inside a bucket is indistinguishable. And for most venue kinds the depth is read by calling the caller-supplied address, so the witness itself is attested rather than measured.

A handful of self-dealt touches per decay window keeps the score maximal at negligible cost. Note what has happened structurally: a quantity with no relation to value at all has a blind spot that reaches value, because it edits the candidate set on which the value guarantees are subsequently proved. That is the generalisable warning. An admission mechanism does not need to be part of the value computation to determine the outcome of the value computation.

## The bound on the damage, and the bound on the bound

What limits the exposure is that nothing downstream of ranking reads standing. The output floor, the user's own minimum and the believability band are all computed from measurements taken during the transaction, so a captured registry cannot alter what any venue is judged to have paid. The principal is not reachable.

But the honest bound is not "cannot touch user funds". A captured slot controls both the quote it advertises and the fill it delivers, so it can consume the entire gap between the honest quote and the user's own minimum. The exposure is the user's slippage tolerance, not their principal — which is precisely why the mandatory non-zero minimum is not a formality, and why an interface that sets a loose minimum on a user's behalf is a larger risk than any of the mechanisms described here.

That two-clause form is the shape we would ask any protocol to publish beside a learned component: this guarantees X; it permits Y and Z. It is a discipline rather than a discovery, and it is uncommon in this industry mainly because the second clause is the one that costs something to write.

## Three transfers to systems with a learned component

These are offered as transfers rather than results — what our evidence suggests, at the strength our evidence supports, each with the objection that limits it.

The quarantine: remembered state may change where a system looks; it must not change what it accepts. The objection is our own leak — ranking a candidate set by remembered state and then truncating it does change the outcome, so the guarantee has to be stated over the full option set rather than over the survivors, and ours is enforced by construction rather than by a checked specification.

The relational check: when no single output can be declared correct, state what the answer must not depend on. "What this participant is owed must not depend on who else acted in the same window" is the form that closed most of our disclosed defects; "the answer must not depend on what shared its batch" is the same form elsewhere. The objection is that this only falsifies relations somebody thought to write down, so it inherits the problem it was brought in to solve.

The seam: fail open where the system is only predicting, and fail closed where it is acting — with the guard computed from measured state rather than from the system's own report of what it did. The objection is that for this to be a property rather than an aspiration, the seam has to be an actual place in the code, and in most architectures the boundary between deciding and doing is not one. In ours it is: read paths versus the execution frame, which is why the rule is auditable line by line here and may not be elsewhere.

**Verify it yourself:** trace it the way we did: find every read and every write of the remembered value in the source, and check whether any of them feeds a quote, a floor, a split weight or a transfer — then check separately whether any of them feeds a ranking that is subsequently truncated

Related: https://blazephoenix.xyz/learn/pool-vitality · https://blazephoenix.xyz/learn/capital-anchor-breakdown-point · https://blazephoenix.xyz/learn/what-a-conservation-guard-cannot-see