$NINEHOOD

reading this pool's swap logs…

• · These strings were written into the token contract by whoever deployed it, and some of what is above came from our index rather than from this request — each part says which. Anyone can deploy a contract and write anything into it. A link here is not evidence that the account, site or person it points to has anything to do with $NINEHOOD — we do not check, we do not ask them, and we never follow the link to see where it lands.
• · We asked the six metadata getters the launchpads on this chain actually implement (socials, twitter, telegram, tokenURI, description, metadata). None returned anything renderable. Most tokens here publish nothing — that is the normal case, not a warning, and a token that publishes a great deal is not thereby safer.
• · Read them yourself: the contract on the explorer ↗

• · Every row is the account that SIGNED the swap transaction — never the router the trade was routed through. (Measured while building this: every swap-event “sender” in a live window was a contract; a board of those would be a list of routers.)
• · Totals cover ONLY the indexed window: 328 swaps attributed for $NINEHOOD between 2026-08-05 22:17Z and 2026-08-07 10:41Z — at least 25% of the 1,296 swaps our volume index counted over the same hours. Attribution is budgeted per tick and takes the highest-value blocks first, so every figure here is a floor over a stated period, never a lifetime total.
• · ETH in and ETH out are shown separately because net alone cannot tell “never sold” from “round-tripped”.
• · An account signing on others' behalf (a keeper, a relayer) appears as one signer. The “tokens” column is shown so bot- and infrastructure-shaped accounts are visible rather than silently ranked as people.

last 24h 9.98e-6 ETH added over 1 event · 0.02241 ETH left the pools over 1 movement (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.

• 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.

• · Depth figures were read at block 30,153,491 — snapshot at 10:52 UTC. Liquidity can leave in one block; treat these as that instant, not as now. “ETH reserve” is the V2 pair's ETH side from getReserves() — exact. “ETH held” is the WETH a V3 pool contract holds: a ceiling on what a sell can be paid, not depth at spot — it includes out-of-range positions and uncollected fees, so a trade near spot may reach less.
• · 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 $NINEHOOD's 24h ETH across all 1 of its pools, not just the rows listed.

We could not measure holder distribution for $NINEHOOD: this server is already running as many holder reads as it can without them breaking each other — measured, two of these 120,000-block Transfer walks running at once produce no measurement at all, just two failures — so this one was refused rather than queued behind them. That is our capacity at this instant, not a fact about this token; the same request a few seconds from now will likely get through. No percentage is shown, because a failed read of ours must never render as a number about someone else's token.