How every figure is made

The suggested range

It starts from the pool's own daily closing prices, as its subgraph publishes them: the last 31 completed UTC days, leaving out today because it has not closed yet. Those give 30 daily returns, each the difference between the logarithms of two consecutive closes. A day missing from the source is skipped — never filled in, carried forward or interpolated — and the page says when the window had gaps.

The volatility is the sample standard deviation of those returns, scaled to a year by the square root of 365. It is then scaled to the horizon you choose (7, 30, or 90 days; 30 unless you choose) by the square root of the horizon's share of a year, and multiplied by the width you choose (in standard deviations: 1σ, 1.5σ, 2σ, or 3σ; 1σ unless you choose). The horizon only says how far the measured movement is laid forward: the movement is always measured over the same last 30 days.

The band is laid around today's price symmetrically in logarithms, with no drift: halving and doubling are the same distance, which is why the two percentages either side differ. Its edges are then moved outward onto the pool's tick grid, never inward, so the range always covers at least the band. Two checks guard it: the pool's current price must convert to the tick the pool itself reports, and it must come from a block at most 15 minutes behind the chain.

It is not a forecast: it says how far the price has moved, not where it will go. And the width is not a confidence level — turning "two standard deviations" into "95% of the time" needs an assumption about how prices are distributed that has not been established. It does not size a position or say how much of either token to deposit.

Checked on days it never saw

The site reads 121 days of closes — more than the volatility needs — so the method can be tested on days it was not fitted to. It is stepped back one horizon, fitted again on the 31 closes before that point and nothing after, centred on the close at that point, and laid over the days that followed; then the same again further back, for as long as the history has room. Each day counts as entirely inside, entirely outside or across an edge: a day's high and low cannot say where in the day the price was, so a crossing day is never split by a guess.

That is a few stretches of one pool, not a measure of how often the method works. Consecutive fits overlap, so the stretches are not independent of each other, and nobody held these bands.

"Opened thirty days ago" replays the range the method would have drawn at the start of the last thirty days — from the 31 closes before it and nothing after — over each of those days. It gives two figures. Worth against holding, at each day's close, comes from the exact concentrated-liquidity amounts and needs no dollar price. Fees come from the pool's own daily fees on the days the price stayed wholly inside, shared out as the deposit figure shares them, with the deposit sized at today's dollar rate because the history has no daily one.

"Try your own range" replays two prices you type over the same thirty days, from the same opening close, with the same fee sharing and the same dollar rate, so the only difference between the two columns is the range. A range that does not hold the opening price starts with only one of the two tokens and takes no fees until the price reaches it. A range that did well over these days says nothing about the next ones.

Fees and impermanent loss

What the pool charged comes from the fees and volume its subgraph publishes for each of the last thirty days. Dividing a day's fees by its volume measures the rate swappers actually paid — the typical day, the lowest and highest, and the whole window as total fees over total volume — and it is set against the fee the pool states. A day with no volume is left out rather than counted as zero.

What a deposit would have taken: on each day the price stayed wholly inside the range, a share L / (A + L) of that day's fees, where L is the liquidity the deposit buys in the range and A is the liquidity the source reports active that day. The "+ L" is the deposit diluting itself, which is why a larger deposit does not collect proportionally more. Days that crossed an edge are not counted, and an inside day the source published no fees or no active liquidity for is reported as such, not as zero.

Turning dollars into the pool's liquidity needs a dollar price, and the site uses the subgraph's own, derived from what the pool holds in each token and in dollars — the rate its fee figures are in. It is today's rate applied to past days, and the page says so. The result is fees only, over days that have already happened: not a yearly rate, and not what the next month will pay.

Impermanent loss — the position against simply holding the two tokens — is the exact arithmetic of the protocol's curve between the range's edges, from today's price to each price shown. It needs no market data and no deposit size, because liquidity cancels out of the ratio. It is only impermanent if the price comes back. It counts price movement and nothing else, and fees are what a provider is paid for bearing it, so the two have to be read together.

v4 hooks

A v4 pool may name a hook, a contract the protocol calls at fixed moments. Its permissions are read from its address: a hook is deployed to an address whose lowest fourteen bits say which callbacks the PoolManager will call, and the PoolManager checks those bits rather than asking the contract. So the site reads the rule the protocol enforces, not a registry, a label or the contract's own description — and it says what a hook may do, never what it does.

A hook allowed to act before a swap can rewrite its fee; one allowed to return a delta from a swap can take part of the swap itself. When a pool's hook holds either, every fee figure tied to a range or a deposit is withheld — the fees while inside, a deposit's share, the fees in the thirty-day replay, the yield on the pair page — because nothing in the source separates the hook's share from the providers'. What the pool charged is still shown, as a fact about the pool, and the panels showing what a swap costs carry a note. A pool whose key fixes no fee is shown as having none, and the rate it actually charged is measured from its days.

Smart liquidity

On each network where positions can be listed (Ethereum, Base, Arbitrum One, OP Mainnet, and Polygon), the page looks into the week's 12 most traded v3 pools, takes the positions in range right now, and asks the chain about up to 100 per pool, largest first, each worth at least $10,000. It is measured again every six hours.

A position's fees are what it has earned since it was last changed: its liquidity times the fee growth inside its range since the position manager last wrote its snapshot, read from the chain. Each position's pair, fee and ticks must lead back to the pool it was listed in. Those fees, over what the position is worth now, over the days since that change, scaled to a year, are its yield. Positions under $10,000, or changed less than 3 days ago, are left out as too small or too new to say anything; the 20% with the highest yield are the smart ones.

The subgraph lists the positions and dates each one's last change, and nothing more. Its fee fields are not used: checked on 2026-09-30, they reported two billion dollars collected by a position that had deposited thirty-two million. The position manager's owed amounts are not counted either, because after a withdrawal they hold the withdrawn principal until it is collected.

What the yield leaves out: it is fees only, and what a position gave up against holding the two tokens is not in it. It covers one window per position, it reads only positions in range now, and it says nothing about what any of them will earn next or about who holds them.

Each measurement is kept, so the page can say how things moved over the last week once a day of measurements exists. A pair's range is compared as prices, never as distances from the current price, because those move whenever the price does even if nobody touches a position. "Holders that keep showing up" are addresses in the top 20% in at least half of the measurements, once there are 8 or more. Each is marked a wallet or a contract from whether the chain holds code at its address: a contract is a vault, a bot or another program, and its yield is that program's.

One pair, every pool

The pair page lists every v3 and v4 pool whose two symbols are exactly the pair typed, on every network the site reads. Each is ranked by the fees it charged over the last week, over what is in it now, scaled to a year — simple, not compounded. That is past fees over present liquidity: not a forecast, and not what a position would earn, since a position earns only while the price is inside its range, shares the fees with everyone else there, and gives up something against holding.

What is in a pool is measured differently on each protocol, so the two are ranked apart: on v3, what the pool's token contracts hold for it; on v4, whose tokens all sit in one PoolManager, its depth at the current price. Only pools worth at least $100,000 are ranked — below that, one afternoon's trading moves the figure too much and a lookalike token is likelier — and the rest are listed below by size, without a yield. A v4 pool whose hook may change what swaps pay shows its fees with a note and no yield. A network that cannot be read is listed as such.

The written explanation

On a pool's page, after every figure has been computed and checked, a language model writes four short paragraphs: what the range covers, what happens when the price leaves it, what the volatility measures and what it does not, and what the analysis leaves out. It is given the figures as the page shows them, in the reader's language, with the directions already written out as sentences. Nothing a visitor writes reaches it except a pool address that has passed a strict format check — no token description, no free text — and no tick reaches it at all.

It is told never to state a number, never to advise and never to predict. That is enforced, not only asked: every paragraph is checked before it is shown. One containing a digit in any script — Arabic, Devanagari and full-width digits, fractions and superscripts included — other than in the names v3 and v4, or a number from eleven upwards written as a word in any of the ten languages, is refused, as is one too short or too long. If any paragraph fails, the whole explanation is dropped and the figures stand on their own.

What a check cannot enforce is tone; that is left to the instruction, and the page does not pretend otherwise. The page names the model that wrote the text, as the provider reports it, and the same explanation is reused for at most an hour for the same pool, settings and language.

Data sources and limits

Pools are read from Uniswap's v3 and v4 subgraphs on The Graph, on Ethereum, Base, Arbitrum One, Unichain, OP Mainnet, and Polygon; Unichain is read for v4 only. Where a subgraph is wrong or silent, the chain is asked directly, read-only: a v3 pool's tick spacing and what its token contracts hold, a v4 pool's liquidity and price from the PoolManager, a position's earnings and holder from the position manager, and whether an address holds code. Every subgraph is checked hourly.

A pool's current state must come from a block at most 15 minutes behind the chain, or it is refused. Daily histories are kept for the UTC day, the week's most traded pools for half an hour, searches and pair reads for ten minutes, and an explanation for an hour; the smart-liquidity measurement is refreshed every six hours.

When a source fails, the page says which part could not be made and shows the rest; a missing figure is shown as missing, never as zero, and never replaced by a guess. On the smart-liquidity page a pool that cannot be read costs that pool alone, and a failed refresh leaves the last measurement standing until it expires; on the pair page a network that cannot be read is listed as such. The explanation is the one part allowed to be missing.

Nothing is kept about who reads the site. A visit is counted as a line naming the page, the pool if there is one (a public contract), the language and whether it looked like a bot — no IP address, no browser string, no search text, and never an address typed in to look up its positions. The one thing kept about a reader is a Telegram alert they set up themselves: the address they typed, their language, the chat's numeric id and whether each position was in range last time. /stop deletes it at once, and the backups lose it within seven days.