How the numbers are computed

How the curve on an address page is replayed, priced and bounded.

over the Net worth history chart

Replayed from chain state: {N} bucket(s) of {5 min} across the last {24 hours}. {N position legs | No position legs} on the line. Marked: {N} bucket(s) where a held token's price was carried from its last close. {N} bucket(s) carry no figure at all and are left as a break in the line.

the right-hand edge of the replayed curve

The line ends at the newest bucket, priced by the same rule as every other bucket on it. It is not this wallet's value at this second, and nothing here jumps to a different basis at the right-hand edge.

the key beside the replayed curve

priced from a carried close — A dashed stretch of the line rests on a price carried forward from a held token's last close: nobody published a close for those buckets, so the last one published stands in. Nothing is missing from the value there — it is the answer's own, whole. What the dashes say is that the price behind that stretch was inferred rather than observed.

under the replayed curve, where the sweeper series is drawn instead

The replay is computed per request and this one did not come back complete, so the panel shows the series the batch snapshotter records instead. That series is unaffected: it keeps being written whatever this panel draws.

under the replayed curve, naming the native leg's source

The native coin is on the line, from the exact per-block record inside this window | …from the aggregated per-address totals | No native line for a contract | The native coin is not on the line: {reason} | No native line on this answer.

under the replayed curve, naming the pricing rule

Priced under upstream's {price rule} rule.

under “Positions on the line”

Held across the whole window at one quantity, and valued inside every bucket of the curve above.

the “Positions on the line” heading

These positions are part of the line above: their value is inside every bucket of it, not an amount to add to it. Each one held a single quantity across the whole window — a pHEX stake's accrual excepted, which is a known function of the day rather than a movement. A position whose quantity moved is listed below instead, because this chart values positions, it does not replay their journals.

the “Positions not on the line” heading

The line does not cover these positions, and each one is named with what it is worth now so the size of the omission is visible rather than implied. A position left out because its quantity changed inside the window, or because it fell outside the cap on how many legs one answer draws, is a rule rather than a failure: the chart is complete, and it is complete about less.

under “Not on the line”

Held now, but with no price series to replay — drawing one flat at its current mark would claim its price never moved.

under “Not replayed”

Held now, and left out of the walk by the bounds this answer works under.

What the Current Holdings figure sums, and what it leaves out.

under the Current Holdings figure

tokens ${X} + liquidity ${Y} · {price rule} — the two halves of the figure above, named separately so the total is never mistaken for one of them. Staked PHEX and PTGC and farm positions are in NEITHER half — they are their own sections in the Holdings tab.

under the Current Holdings figure, when only one half arrived

token balances ${X} · liquidity not included — this is the half of the figure upstream did answer. It is NOT this wallet's holdings total: the liquidity positions are missing from it.

under the Current Holdings figure, the batch snapshot

last indexed valuation ${X} as of block {N} | no indexed valuation yet | last indexed valuation unavailable — a separate quantity from the figure above it, frozen at the block it was computed at. The two are never reconciled.

under the Current Holdings figure, the coverage clause

· includes {clauses} as of {D Mon YYYY}.

under the Current Holdings figure, when upstream held rows back

Upstream held {N} token balance(s) back from this answer, so the total above and the Holdings tab both describe the rows that arrived.

under the liquidity positions list

Itemised from {sources}. That list is this page's reading of the rows below it, not a statement from upstream.

under the liquidity positions list, when upstream stated the provenance itself

Liquidity positions are decoded from {X and Y}. Itemised here: {legs}. Not itemised in this answer: {legs}. — the served form of the line above, and the difference matters: this one is upstream's own statement about which legs it decoded, not this page's reading of the rows it was sent.

What a watchlist card's figure, percentage and line are computed from.

over the tracked list

A wallet's figure is what it HOLDS — its token balances plus its liquidity positions, priced at upstream's newest marks — and each card names the block those balances were read at. The line is replayed from chain state where the API can replay it, and says so where it cannot.

under a wallet card's figure

What this wallet HOLDS, not what a batch consumer last recorded for it: the token balances upstream can price, plus the current value of its liquidity positions. The block is the position those balances were read at; the prices are upstream's newest usable marks and are not dated by it. It is a mark, not a sale.

over the dashboard's token table

Change is a chain-time 24h window ending at the indexer cursor, not the last 24 wall-clock hours.

over the dashboard's wallet table

Net worth is the last batch snapshot, not a live balance — each row names the block it was computed at. Open an address page for balances, history and P&L.

under the dashboard's three tiles

No portfolio total is shown. Token rows are prices with no quantity behind them, and each wallet's net worth is a separate snapshot taken at its own block — adding these together would produce a figure that was never true at any one moment.

the empty watchlist

Tokens show the indexer's latest price and its real price ticks; wallets show what they hold now and a curve replayed from chain state.

under a token card's sparkline

Last {span}. | Last {span} — last trade {N} hours ago, so the line stops before the right edge. The window is the one selected on the panel; the line is drawn against that window rather than against the data's own extent, so a series that stopped early draws short and the empty band on the right is the silence.

under a wallet card's replayed sparkline

Replayed {24 hours} · {N} buckets of {5 min} · {N} priced from a carried close · {N} with no figure.

What each tab on an address page draws from, and what it leaves out.

the Trades tab, and a transaction's swap legs

This site's trade coverage includes {clauses} as of {D Mon YYYY}.

the Bridge tab

This route records the transfer, not its value: no USD figure exists on a bridge row, so none is shown. Amounts are the token's own.

the Contract tab, on a read call

These calls are answered by the chain head, not by the indexed data the rest of this page is drawn from. The two are different things and can disagree.

the Contract tab, on a proxy

Sourcify reports this is a proxy. The source and functions below are the PROXY's own — what it delegates to is a different contract with a different verification.

the Transactions tab's list

This list holds both lanes: the transactions this site has written down, and the ones the node it reads has above that index. The second kind say so on their own status, sort where their block puts them, and can still change.

the Transactions tab's list, on provenance

Read from a node. Some rows in this list are ahead of this site's own index — each one says so on its status — and they are in none of the figures above the list.

over the Internal and ERC-20 tabs' lists

This list starts at the newest {internal value transfer | token transfer} this site has indexed. Where this site draws transactions ahead of its index, it draws plain transactions only.

the Validators tab

Validators whose withdrawals resolve to this address, by validator index. A validator appears because its withdrawal credentials decode to this address, or because a withdrawal to it has been recorded at the replay's current position.

What each figure on a token page counts, and over what window.

under Price, Volume and Transactions

chain-time 24h at the cursor — the window ends where the indexer's cursor is, not at the last 24 hours of wall-clock time. During a replay those are nowhere near each other.

under Price, for a T1 stablecoin

$1.00 by definition (T1 stable).

under Holders

counted {age} ago | counted just now — the holder count is recomputed by a daily pass rather than on every read, so it is the count as of that pass rather than as of now.

the chart, when there is too little trading to draw one

A chart drawn from them would be mostly estimate, so it is not drawn. Every recorded trade is still listed below.

the chart, when the window holds no candles

Gaps are gaps, not errors — T1 stablecoins have no candles before block 20,319,200, and the replay fills history as it advances.

the Transactions tab

Transactions whose sender or recipient is this contract — calls into the token, not trades of it. Value is native PLS.

the Internals tab

Native PLS moving to or from this contract inside a transaction's trace tree — value-transfer ATTEMPTS, failures included. Not token transfers.

the Pools tab, on the order

Ordered by upstream's pool-value ranking, largest first — twice this pool's most reliably priced side, never a sum of both, and deliberately conservative rather than a total value locked. That figure is the Ranking value column, so the order can be checked by reading down it.

the Pools tab, on the order this build cannot claim

Listed in the order upstream returned them. This API build does not serve a pool-value ranking yet, so a row's position says nothing about its size — a pool near the top is not necessarily larger than one below it.

the Pools tab, on what the list covers

Upstream serves at most 500 pools for a token, newest-created first, and offers no way to page past them — so this covers the 500 most recently created pools, not every pool holding the token. The count beside the table is how many of them are drawn.

the Transfers tab

Every ERC-20 Transfer of this token, newest first, across all wallets. Amounts are scaled by the token's own decimals; this contract's address is not treated specially in the sender and recipient columns.

the Transfers tab, while the route is not served

Nothing is composed from the per-wallet feeds in the meantime: those cover one wallet at a time, so a stitched list would look complete while omitting every wallet not asked about.

the Holders tab, while it is empty

Balances regenerate during the replay; this fills in as it advances.

What the swap feeds contain, and what “priced swaps only” leaves out.

under the intent-swaps panel and at the bottom of /swaps

Priced swaps only — about {N}% of recent swaps are unpriced. The feed lists only the swaps the indexer could price; upstream states the share it left unpriced on each answer, and may not state one at all.

under the same line, when the answer dated its measurement

(measured {age} ago over the last {N} blocks) — the share is sampled rather than standing: it is measured at a moment, over a window of blocks, and both are named.

under the same line, when the answer stated no rule

This feed lists priced swaps only. The route did not state its exclusion rule on this response, so the usual figure is not shown.

the /swaps lead

Every swap the indexer priced, newest first, at or above the threshold you set.

the intent-swaps panel, while it is empty

This is a live feed at the head, not an archive.

What a window is, what partial capture does to a figure, and how the entity tables are grouped.

over the entity tables

Windows are counted in epochs and close at the last complete UTC day, so “1d” is yesterday rather than the last 24 hours. Each figure carries the epoch range it was computed over.

over the withdrawal-address table

Ranked by validators held in the window, over epochs {N}–{M}. Grouped by withdrawal credentials, which every validator has at most one of, so the groups partition the validators that have one. The counts come out of {N} validators with an address — a larger population than the active set, and it is named for scale rather than divided into anything: no column here is a share.

over the by-graffiti table

Ranked by blocks proposed in window, over epochs {N}–{M}. Graffiti is written by the proposer on each block it produces, so a missed slot has none. Rows are grouped by exact bytes and are not verified identities — one string can be many operators, and one operator can use many strings.

under the withdrawal-address table

{N} validators have BLS withdrawal credentials, which decode to no execution address, so they belong to no row here. They are outside the population named above too — that counts only validators which have an address — so no row's count is affected by them.

under the entity tables, on the total

{N} exist in the validator registry, including those with no activity in this window. That is a different population from the rows: an entity with no activity in the window has no row here and is still in the registry.

while a long window is loading

The longer windows are aggregated on request rather than read from a rollup. Measured 2026-08-31: about one second for 30 days and three for 90, then served from cache for five minutes.

the coverage strip, below full capture

Figures below cover the captured epochs only, so every total is a lower bound. Rates are computed over what was observed and are not scaled up.

the coverage strip, below full capture, on a ranked table

This ranking is ordered on {X} of {Y} epochs — about {N} of the {M} days it is labelled with were never captured. The ORDER of these rows can differ from the full window's, and a reader given only the coverage fraction will scale every row up by the same factor, which does not hold.

the coverage strip, on the backfill

The historical backfill has reached epoch {N}, walking oldest to newest. That is a separate cursor from the coverage stated here — a recent window can be fully captured while the backfill is still far below it.

the coverage strip, on the rollup's own shortfall

The entity rows for this window are short by {N} days: the daily rollup is complete only through {D}, while the window closes on {D2}. Every per-entity figure therefore covers fewer days than the window states. This is a gap in the rollup, not the epoch coverage stated beside it.

on the Queues box heading

The queue counts are re-read every 60 seconds.

on the Queues box heading, on what it does NOT do

Nothing in this box is added up or inferred from the figures beside it: each of the four is read from the field the answer served it in, and a field the answer did not carry draws a word.

in the Queues box, on why there are no waits in it

This box gives no estimated time for any queue. A wait divided out of a churn limit is a projection, and the four figures here are counts the answer served — so none of them is a claim about when anything will happen.

under the Missed blocks tile

A missed slot whose proposer this indexer has no record of belongs to no entity. Those misses are counted here in full and appear in no entity's Missed column, so that column will always total less than this figure.

under the Active validators tile

A census, not a window: an active-validator count is a state at one epoch, not a rate over a period, so it carries no window label.

under the Slashed tile

Forced exits landing in the last 24 hours. Where the answer does not say what the figure counts, nothing is claimed about it and no description is drawn.

under the Total staked tile

The sum of effective balances. It is shown only when the answer carries the sum — nothing here multiplies a nominal stake by a validator count to produce one. Where the answer does not say what the figure sums, the figure is still shown, nothing is claimed about it and no description is drawn.

over the epoch strip and the epoch list

Every figure here is for one epoch — 32 slots.

the /epochs lead

Every summarised epoch, newest first. An epoch is 32 slots; every figure on a row is for that one epoch.

the /slots lead

Every slot of the consensus schedule, newest first — including the ones where no block was produced, which appear on no block list anywhere.

over the slot strip

Every slot, including the ones where no block was produced.

under the shadow Coverage tile

The share of the window's slots that have a shadow record.

beside the shadow Produced → received figure

The seconds subtract the producer's own clock from this node's.

the shadow page's “Verify it yourself”

Every shadow record is a signed claim about a block, produced independently of this indexer, so agreement between the two is checkable by anyone — not something to take on trust. The plain-language methodology document and the signing public key publish at the Phase 6 key ceremony; this page will link both, pinned by content hash, when they exist.

What this site indexes, when it indexes it, and how the fee and trace figures are derived.

wherever a block is above the indexed head

This site indexes a block only once 12 more blocks sit on top of it — a deliberate buffer against reorgs, not a backlog.

over an empty /blocks list

The historical replay fills blocks in as its cursor advances — this list follows it.

the /blocks lead

Indexed blocks, newest first, with gas usage and fee accounting.

under the /blocks gap bands

Gaps are counted between adjacent rows on this page, so the oldest row on each page has none recorded — its gap is measured on the next page down.

under a block's transaction table

Whether each transaction succeeded comes from its own receipt, and this page does not read one per transaction on the head lane; the method is decoded from calldata the same way, and neither column is drawn where it cannot be filled.

under a block's transaction table, the count line

All {N} transactions the node reports for this block. | {N} transactions of the {M} the node reports for this block. — the table lists what the lane answered with, and the block's own count is beside it so the two can be compared rather than assumed equal.

under a block's Proposer reward

Tips plus direct payments, server-computed.

beside an unfinalized block's pill

The consensus layer has not finalized this block. Its contents are what the chain reports now and can still be replaced.

under an unfinalized block's or transaction's header

Read from a node. The node this site reads is {N} blocks past this block. This site indexes a block once {N} blocks sit on top of it, so the proposer, the consensus reward and this block's trace-derived accounting are not written down yet.

beside a pending consensus reward

Being summarised. This epoch closed less than an hour ago. | Backfill in progress — this epoch is queued. | Not summarised yet. | Never summarised. No consensus reward was recorded for this epoch and none can be recovered.

when a transaction is not found

No transaction with this hash is known to this site's index or to the node it reads. A hash that has only just been broadcast and is still in the mempool is not on a block yet, and this site does not read the mempool.

under a transaction's Total fee

Server-computed burned + tip.

beside a transaction's Gas used bar

Of the transaction's own gas limit.

under the internal-calls table, when the answer carries each call's depth

In execution order — the call tree read depth-first, with each call indented under the one that made it.

under the internal-calls table, when the answer carries no depth

In execution order. Nesting is not shown: this answer carries no depth, so every call is drawn at the same level instead of indented under the one that made it. The order is unaffected — it comes from each call's position in the tree, not from its depth.

under the internal-calls table, when the slice is partial

A partial slice, and it is NOT the first calls the transaction made: pages arrive in the order upstream keys them, which is not execution order, so a call indented here may sit under a parent that has not loaded. Load the rest for the whole tree.

under the internal-calls table, on the undrawn column

Also served per call and not drawn here: gas_used.

the transfers and internal tabs' slow gate

Most transactions are far quicker than that, so this one is either unusually expensive to scan or the route is busy — loading it anyway gives the scan the full deadline rather than the automatic budget.

over a transaction's swap legs

Every swap this transaction executed, in the order it executed them. A path that hops through several pools carries the same money through each one, so the leg values are not added up.

over a transaction's swap legs, on what a leg is

Swap legs are this site's reading of which pools this transaction touched and in which direction — a classification made when the transaction is indexed, not a field the node holds.

over the transfer flow

The sender is not either end of any transfer in this transaction — every hop is between other addresses, which is what a swap routed through a contract looks like. Direction is classified relative to the transaction's sender.

under the transfer flow

USD value is not served by this route, so the column is empty rather than filled. It is not estimated from today's price: applying a current price to a past transfer produces a different quantity in the same units.

How the walked lists are ordered, and what an epoch or a slot list contains.

over the address-tags list

The list walks by address; there is no most-recent page to be at.

the /epochs lead

Every summarised epoch, newest first. An epoch is 32 slots; every figure on a row is for that one epoch.

the /slots lead

Every slot of the consensus schedule, newest first — including the ones where no block was produced, which appear on no block list anywhere.