Coverage

Venues agree on the maths and on nothing else

Aggregating is largely a decoding problem. These are the four places the venues diverge, what each divergence costs if it is read wrong, and how it is handled here.

01

A getter is not a standard

Every concentrated-liquidity fork inherits slot0() and then edits it. One venue here returns six fields, another seven, and a third names the whole thing globalState(). A strict ABI decoder rejects the mismatch and silently drops a live pool from the book.

How it is handled

Return data is decoded by word: the first holds the price, the second the tick. Extra fields are ignored rather than fatal, so a fork we have never seen still prices.

02

Uniswap v4 has no pool contract

There is nothing at a pool address to call, because there is no pool address. Every v4 pool lives inside one singleton, and its state is a mapping entry keyed by pool id.

How it is handled

The base slot is keccak256(poolId, 6). Price and tick unpack from the first word, liquidity from the fourth, and the tick bitmap and tick data hang off the two slots after that.

03

A pool id does not contain its tick spacing

A v4 pool id is the hash of its key, and tick spacing lives only in that key. Without it the tick bitmap cannot be walked, so the pool can only be given a spot price — which is exactly the sort of sizeless number this product exists to avoid.

How it is handled

The key is recovered from the Initialize log the singleton emitted when the pool was created. That log also carries the hook address and the dynamic-fee flag, neither of which any amount of hashing would reveal.

04

Hooks can change the swap

A v4 pool with a hook attached can charge a fee set at swap time or alter the trade in ways tick data does not describe. Pricing it as though it were a plain pool would quietly overstate the fill.

How it is handled

Hooked pools are priced and shown, and labelled as hooked. The quote is honest about being indicative rather than presented as exact.

Venue coverage · Aquifer