$SAMURAI

The index has not attributed an ETH-quoted pool to this token, so there is no pool to read a tape from. That is a statement about our index, not about whether this token trades.

No swaps have been attributed to a signer for $SAMURAI yet. Trader attribution covers only the window since it was switched on, and only what its per-tick budget could read — so this is a statement about our coverage, not about whether anyone is trading. The chart and volume above come from a separate, older measurement.

• · We could not read $SAMURAI's metadata getters just now. So nothing is shown above rather than an empty list — an empty list would read as “this token publishes nothing”, which is a claim about the token made out of our own failed read.
• · Read them yourself: the contract on the explorer ↗

• · V4 depth is UNMEASURED, not zero: V4's PoolManager is a singleton holding every pool's tokens in one contract balance, so per-pool reserves cannot be read as balances. We say so rather than guess.
• · “unread” rows are OUR RPC failing at snapshot time — a fact about our read, never a statement about the pool.
• · Volume is the 24h ETH leg the chainwide index attributed to each pool — a floor over what its per-tick budget could walk, never a lifetime total. Share divides by $SAMURAI's 24h ETH across all 7 of its pools, not just the rows listed.

last 24h 0 ETH added over 0 events · 0 ETH left the pools over 0 movements (V3 collects and V2 burns — the two ways tokens actually leave a pool contract). Floors over the pools and blocks we walked, not a census.

No liquidity event has been indexed for $SAMURAI inside the blocks we walked. Read the coverage line above before treating that as calm: it is the absence of an observation over a bounded window, not evidence that nothing moved.

• Every row is a log we decoded, stamped with the block it came from. This panel states what moved, when, and who signed for it — it does not label a removal, and it never will. Taking liquidity out is an ordinary operation; the reader draws the conclusion from the numbers and the times.
• V3 splits a removal in two: closed is the burn, which only credits what the position is owed, and withdrawn is the collect, where the tokens actually leave the pool. A collect carries accrued fees as well as principal and the event does not separate them, so we do not either. V2 does not split: a V2 removed transferred in the same call, with no collect to wait for, which is why the summary counts it as ETH that left rather than as principal credited.
• Percentages are deliberately absent. “80% of the liquidity left” needs the depth before the removal, and we hold depth only as a live read at one block — no history to divide by. The absolute amounts above are what we actually measured.

We could not measure holder distribution for $SAMURAI: our node did not answer, so no holder read was attempted. Nothing is claimed about this token's distribution. No percentage is shown, because a failed read of ours must never render as a number about someone else's token.