Where the numbers come from

Every figure hookr.fun prints is produced one of three ways: read from a contract at a named block, measured from settled events, or taken from a third-party market provider. This page is the one place that says which is which, so the product pages can show the figure instead of explaining it.

One rule runs underneath all of it. A value that could not be read is never shown as zero: it renders as an em dash with its reason, and any control that depends on it stays disabled until a real read replaces it.

Balances and the Pooled column

A pool's two token amounts are read from the Uniswap v4 PoolManager singleton: the pool's own balances at one pinned block height, scaled by each token's decimals. Rows that rank by Pooled rank by the value of those balances. That is the pool's reserve, not token market cap and not a dollar oracle value.

Those reads do not happen inside the request that renders the table. A cohort of a hundred-odd pools costs a pinned tick-ledger read each, far more than a page render can pay for, so a scheduled sweep performs them and writes each answer to a warm ledger that a request simply reads back.

Each warm record is stamped with the block it was read at and carries that block to the row. A balance read ten minutes ago is truthful about the block it names and would be a lie about the current head, so the block travels with the figure rather than being re-dated to the head, and a pool whose read did not complete stores the reason instead of an amount.

How often each surface refreshes

A tick is skipped while the tab is hidden and runs again when it becomes visible, so a backgrounded page holds its last verified read instead of burning refreshes nobody is watching.

Fee yield needs two samples

A pool's cumulative fee totals live in PoolManager storage, and this chain retains roughly ten minutes of that history. The only way to know what a pool earned between two moments is to have recorded the earlier one, so an estimated APR depends on the sweep having already observed that pool for long enough.

Until it has, the figure is unavailable rather than 0%. The same holds when the trailing window contained no swaps, when the pool's rates or price could not be read, or when the pool holds no in-range liquidity.

Why some pools show no market data

Price, trailing 24-hour volume and provider TVL come from GeckoTerminal, not from Hookr's own index. A pool that provider has not listed shows no market figures at all. That is an absence of provider coverage, not a claim that the pool is empty or inactive. Its on-chain balances are read separately and still appear.

Depth is only comparable between pools quoted in the same currency. A pool quoted in native ETH and a pool quoted in an ERC-20 are two different units, and no table adds them together.

What "partial" coverage means

The pool and launch listings are assembled from several release registries plus the pool index. When one of those does not answer, the snapshot is marked partial, and that means exactly one thing: the list is incomplete, not short.

Counts derived from a partial read are floors, and a floor is marked with ≥ rather than printed as if it were exact. A partial read never drops a row that was proven to exist and never invents one that was not. Where a figure cannot honestly be stated even as a floor, it is withheld.

Wallet actions never trust any of this

Warm balances, indexed history and provider figures exist for navigation and aggregates. Every action that can move value re-reads the relevant on-chain state immediately before preparing the wallet request, and a read that fails leaves the action disabled rather than letting a cached row stand in for it.

Data and safety methodology carries the same rules for profiles, social provenance and earnings language.